Re: [PATCH] tpm: efi: Don't create binary_bios_measurements file for an empty log
> On Oct 29, 2020, at 01:39, Tyler Hicks wrote:
>
> On 2020-10-28 11:30:11, Tyler Hicks wrote:
>> So, we need help from Kai, Kenneth, or Mimi to verify my assumption that
>> their firmware is providing an empty main event log and a populated
>> final event log.
>
> Hi Kai, Kenneth, and Mimi - could one or two of you please follow these
> steps:
>
> 1) Apply the proposed patch in the grandparent of this email so that
> your kernel doesn't crash
> 2) Revert commit 7f3d176f5f7e ("tpm: Require that all digests are
> present in TCG_PCR_EVENT2 structures") so that
> __calc_tpm2_event_size() goes back to being less picky and may treat
> a final log event as a valid event log header
> 3) Add some debugging warnings in efi_tpm_eventlog_init() to check for
> an empty main event log and a populated final event log, as shown
> below
> 4) Boot the resulting kernel build, look for the warnings, and report
> back
>
> diff --git a/drivers/firmware/efi/tpm.c b/drivers/firmware/efi/tpm.c
> index c1955d320fec..c4d2dbd5ed42 100644
> --- a/drivers/firmware/efi/tpm.c
> +++ b/drivers/firmware/efi/tpm.c
> @@ -78,6 +78,9 @@ int __init efi_tpm_eventlog_init(void)
> goto out;
> }
>
> + WARN(!log_tbl->size && final_tbl->nr_events,
> + "nr_events = %llu\n", final_tbl->nr_events);
> +
> tbl_size = 0;
> if (final_tbl->nr_events != 0) {
> void *events = (void *)efi.tpm_final_log
> @@ -95,6 +98,8 @@ int __init efi_tpm_eventlog_init(void)
> goto out_calc;
> }
>
> + WARN(!log_tbl->size && tbl_size, "tbl_size = %d\n", tbl_size);
> +
> memblock_reserve((unsigned long)final_tbl,
>tbl_size + sizeof(*final_tbl));
> efi_tpm_final_log_size = tbl_size;
>
> For your convenience, I've created a branch with these changes on top of
> v5.9:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/tyhicks/linux.git/log/?h=tpm/bin-bios-measurements-debug
Dmesg attached.
Kai-Heng
dmesg
Description: Binary data
>
> Thank you!
>
> Tyler
Re: [PATCH] f2fs: move ioctl interface definitions to separated file
Hi Chao, I love your patch! Yet something to improve: [auto build test ERROR on f2fs/dev-test] [also build test ERROR on linus/master v5.10-rc1 next-20201030] [cannot apply to linux/master] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch] url: https://github.com/0day-ci/linux/commits/Chao-Yu/f2fs-move-ioctl-interface-definitions-to-separated-file/20201030-110841 base: https://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs.git dev-test config: xtensa-allyesconfig (attached as .config) compiler: xtensa-linux-gcc (GCC) 9.3.0 reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # https://github.com/0day-ci/linux/commit/779e80209a06291da2cf60a5a8cd7a7785146dbd git remote add linux-review https://github.com/0day-ci/linux git fetch --no-tags linux-review Chao-Yu/f2fs-move-ioctl-interface-definitions-to-separated-file/20201030-110841 git checkout 779e80209a06291da2cf60a5a8cd7a7785146dbd # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=xtensa If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All errors (new ones prefixed by >>): >> error: include/uapi/linux/f2fs.h: missing "WITH Linux-syscall-note" for >> SPDX-License-Identifier make[2]: *** [scripts/Makefile.headersinst:63: usr/include/linux/f2fs.h] Error 1 make[2]: Target '__headers' not remade because of errors. make[1]: *** [Makefile:1288: headers] Error 2 make[1]: Target 'prepare' not remade because of errors. make: *** [Makefile:185: __sub-make] Error 2 make: Target 'prepare' not remade because of errors. --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org .config.gz Description: application/gzip
Re: [PATCH v5 1/2] arm64: dts: Add the Kontron i.MX8M Mini SoMs and baseboards
On Thu, Oct 01, 2020 at 05:13:37PM +0200, Schrempf Frieder wrote: > From: Frieder Schrempf > > Kontron Electronics GmbH offers small and powerful SoMs based on the > i.MX8M Mini SoC including PMIC, LPDDR4-RAM, eMMC and SPI NOR. > > The matching baseboards have the same form factor and similar interfaces > as the other boards from the Kontron "Board-Line" family, including > SD card, 1G Ethernet, 100M Ethernet, USB Host/OTG, digital IOs, RS232, > RS485, CAN, LVDS or HDMI, RTC and much more. > > Signed-off-by: Frieder Schrempf Applied both, thanks.
[PATCH 0/1] debugfs: Add a helper to export atomic64_t values
Here's my story: Once upon a time, there lived a developer that wanted to export an atomic64_t value to userspace using debugfs to help with debugging. But that developer found there was no helper function to do so and was very sad. The End. Yeah, it's a sad story. Here's my patch, merge me maybe? Anand K Mistry (1): debugfs: Add a helper to export atomic64_t values fs/debugfs/file.c | 37 + include/linux/debugfs.h | 6 ++ 2 files changed, 43 insertions(+) -- 2.29.1.341.ge80a0c044ae-goog
[PATCH 1/1] debugfs: Add a helper to export atomic64_t values
This mirrors support for exporting atomic_t values.
Signed-off-by: Anand K Mistry
---
fs/debugfs/file.c | 37 +
include/linux/debugfs.h | 6 ++
2 files changed, 43 insertions(+)
diff --git a/fs/debugfs/file.c b/fs/debugfs/file.c
index a768a09430c3..798bd3bdedec 100644
--- a/fs/debugfs/file.c
+++ b/fs/debugfs/file.c
@@ -770,6 +770,43 @@ void debugfs_create_atomic_t(const char *name, umode_t
mode,
}
EXPORT_SYMBOL_GPL(debugfs_create_atomic_t);
+static int debugfs_atomic64_t_set(void *data, u64 val)
+{
+ atomic64_set((atomic64_t *)data, val);
+ return 0;
+}
+static int debugfs_atomic64_t_get(void *data, u64 *val)
+{
+ *val = atomic64_read((atomic64_t *)data);
+ return 0;
+}
+DEFINE_DEBUGFS_ATTRIBUTE(fops_atomic64_t, debugfs_atomic64_t_get,
+ debugfs_atomic64_t_set, "%lld\n");
+DEFINE_DEBUGFS_ATTRIBUTE(fops_atomic64_t_ro, debugfs_atomic64_t_get, NULL,
+ "%lld\n");
+DEFINE_DEBUGFS_ATTRIBUTE(fops_atomic64_t_wo, NULL, debugfs_atomic64_t_set,
+ "%lld\n");
+
+/**
+ * debugfs_create_atomic64_t - create a debugfs file that is used to read and
+ * write an atomic64_t value
+ * @name: a pointer to a string containing the name of the file to create.
+ * @mode: the permission that the file should have
+ * @parent: a pointer to the parent dentry for this file. This should be a
+ * directory dentry if set. If this parameter is %NULL, then the
+ * file will be created in the root of the debugfs filesystem.
+ * @value: a pointer to the variable that the file should read to and write
+ * from.
+ */
+void debugfs_create_atomic64_t(const char *name, umode_t mode,
+ struct dentry *parent, atomic64_t *value)
+{
+ debugfs_create_mode_unsafe(name, mode, parent, value,
+ &fops_atomic64_t, &fops_atomic64_t_ro,
+ &fops_atomic64_t_wo);
+}
+EXPORT_SYMBOL_GPL(debugfs_create_atomic64_t);
+
ssize_t debugfs_read_file_bool(struct file *file, char __user *user_buf,
size_t count, loff_t *ppos)
{
diff --git a/include/linux/debugfs.h b/include/linux/debugfs.h
index 851dd1f9a8a5..0fac84c53eab 100644
--- a/include/linux/debugfs.h
+++ b/include/linux/debugfs.h
@@ -126,6 +126,8 @@ void debugfs_create_size_t(const char *name, umode_t mode,
struct dentry *parent, size_t *value);
void debugfs_create_atomic_t(const char *name, umode_t mode,
struct dentry *parent, atomic_t *value);
+void debugfs_create_atomic64_t(const char *name, umode_t mode,
+struct dentry *parent, atomic64_t *value);
struct dentry *debugfs_create_bool(const char *name, umode_t mode,
struct dentry *parent, bool *value);
@@ -291,6 +293,10 @@ static inline void debugfs_create_atomic_t(const char
*name, umode_t mode,
atomic_t *value)
{ }
+static inline void debugfs_create_atomic64_t(const char *name, umode_t mode,
+struct dentry *parent, atomic64_t
*value)
+{ }
+
static inline struct dentry *debugfs_create_bool(const char *name, umode_t
mode,
struct dentry *parent,
bool *value)
--
2.29.1.341.ge80a0c044ae-goog
[PATCH] PM / reboot: Use S5 for reboot
After reboot, it's not possible to use hotkeys to enter BIOS setup and
boot menu on some HP laptops.
BIOS folks identified the root cause is the missing _PTS call, and BIOS
is expecting _PTS to do proper reset.
Using S5 for reboot is default behavior under Windows, "A full shutdown
(S5) occurs when a system restart is requested" [1], so let's do the
same here.
[1] https://docs.microsoft.com/en-us/windows/win32/power/system-power-states
Signed-off-by: Kai-Heng Feng
---
kernel/reboot.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/kernel/reboot.c b/kernel/reboot.c
index e7b78d5ae1ab..7e5aa1f78693 100644
--- a/kernel/reboot.c
+++ b/kernel/reboot.c
@@ -244,6 +244,8 @@ void migrate_to_reboot_cpu(void)
void kernel_restart(char *cmd)
{
kernel_restart_prepare(cmd);
+ if (pm_power_off_prepare)
+ pm_power_off_prepare();
migrate_to_reboot_cpu();
syscore_shutdown();
if (!cmd)
--
2.17.1
Re: [PATCH] PM / reboot: Use S5 for reboot
Hi Hans,
> On Oct 30, 2020, at 15:06, Kai-Heng Feng wrote:
>
> After reboot, it's not possible to use hotkeys to enter BIOS setup and
> boot menu on some HP laptops.
>
> BIOS folks identified the root cause is the missing _PTS call, and BIOS
> is expecting _PTS to do proper reset.
>
> Using S5 for reboot is default behavior under Windows, "A full shutdown
> (S5) occurs when a system restart is requested" [1], so let's do the
> same here.
I wonder if this can also solve "HID: i2c-hid: Put ACPI enumerated devices in
D3 on shutdown" fixed.
Kai-Heng
>
> [1] https://docs.microsoft.com/en-us/windows/win32/power/system-power-states
>
> Signed-off-by: Kai-Heng Feng
> ---
> kernel/reboot.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/kernel/reboot.c b/kernel/reboot.c
> index e7b78d5ae1ab..7e5aa1f78693 100644
> --- a/kernel/reboot.c
> +++ b/kernel/reboot.c
> @@ -244,6 +244,8 @@ void migrate_to_reboot_cpu(void)
> void kernel_restart(char *cmd)
> {
> kernel_restart_prepare(cmd);
> + if (pm_power_off_prepare)
> + pm_power_off_prepare();
> migrate_to_reboot_cpu();
> syscore_shutdown();
> if (!cmd)
> --
> 2.17.1
>
Re: [RFC PATCH 2/3] RISC-V: Initial DTS for Microchip ICICLE board
On Thu, Oct 29, 2020 at 3:24 AM Ben Dooks wrote:
>
> On 28/10/2020 23:27, Atish Patra wrote:
> > Add initial DTS for Microchip ICICLE board having only
> > essential devcies (clocks, sdhci, ethernet, serial, etc).
> >
> > Signed-off-by: Atish Patra
> > ---
> > arch/riscv/boot/dts/Makefile | 1 +
> > arch/riscv/boot/dts/microchip/Makefile| 2 +
> > .../microchip/microchip-icicle-kit-a000.dts | 313 ++
> > 3 files changed, 316 insertions(+)
> > create mode 100644 arch/riscv/boot/dts/microchip/Makefile
> > create mode 100644
> > arch/riscv/boot/dts/microchip/microchip-icicle-kit-a000.dts
> >
> > diff --git a/arch/riscv/boot/dts/Makefile b/arch/riscv/boot/dts/Makefile
> > index ca1f8cbd78c0..3ea94ea0a18a 100644
> > --- a/arch/riscv/boot/dts/Makefile
> > +++ b/arch/riscv/boot/dts/Makefile
> > @@ -1,5 +1,6 @@
> > # SPDX-License-Identifier: GPL-2.0
> > subdir-y += sifive
> > subdir-y += kendryte
> > +subdir-y += microchip
> >
> > obj-$(CONFIG_BUILTIN_DTB) := $(addsuffix /, $(subdir-y))
> > diff --git a/arch/riscv/boot/dts/microchip/Makefile
> > b/arch/riscv/boot/dts/microchip/Makefile
> > new file mode 100644
> > index ..55ad77521304
> > --- /dev/null
> > +++ b/arch/riscv/boot/dts/microchip/Makefile
> > @@ -0,0 +1,2 @@
> > +# SPDX-License-Identifier: GPL-2.0
> > +dtb-$(CONFIG_SOC_MICROCHIP_POLARFIRE) += microchip-icicle-kit-a000.dtb
> > diff --git a/arch/riscv/boot/dts/microchip/microchip-icicle-kit-a000.dts
> > b/arch/riscv/boot/dts/microchip/microchip-icicle-kit-a000.dts
> > new file mode 100644
> > index ..5848920af55c
> > --- /dev/null
> > +++ b/arch/riscv/boot/dts/microchip/microchip-icicle-kit-a000.dts
> > @@ -0,0 +1,313 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +/* Copyright (c) 2020 Microchip Technology Inc */
> > +
> > +/dts-v1/;
> > +
> > +/* Clock frequency (in Hz) of the rtcclk */
> > +#define RTCCLK_FREQ 100
> > +
> > +/ {
> > + #address-cells = <2>;
> > + #size-cells = <2>;
> > + model = "Microchip PolarFire-SoC";
> > + compatible = "microchip,polarfire-soc";
> > +
> > + chosen {
> > + stdout-path = &serial0;
> > + };
> > +
> > + cpus {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + timebase-frequency = ;
> > +
> > + cpu@0 {
> > + clock-frequency = <0>;
> > + compatible = "sifive,rocket0", "riscv";
> > + device_type = "cpu";
> > + i-cache-block-size = <64>;
> > + i-cache-sets = <128>;
> > + i-cache-size = <16384>;
> > + reg = <0>;
> > + riscv,isa = "rv64imac";
> > + status = "disabled";
> > +
> > + cpu0_intc: interrupt-controller {
> > + #interrupt-cells = <1>;
> > + compatible = "riscv,cpu-intc";
> > + interrupt-controller;
> > + };
> > + };
> > +
> > + cpu@1 {
> > + clock-frequency = <0>;
> > + compatible = "sifive,rocket0", "riscv";
> > + d-cache-block-size = <64>;
> > + d-cache-sets = <64>;
> > + d-cache-size = <32768>;
> > + d-tlb-sets = <1>;
> > + d-tlb-size = <32>;
> > + device_type = "cpu";
> > + i-cache-block-size = <64>;
> > + i-cache-sets = <64>;
> > + i-cache-size = <32768>;
> > + i-tlb-sets = <1>;
> > + i-tlb-size = <32>;
> > + mmu-type = "riscv,sv39";
> > + reg = <1>;
> > + riscv,isa = "rv64imafdc";
> > + tlb-split;
> > + status = "okay";
> > +
> > + cpu1_intc: interrupt-controller {
> > + #interrupt-cells = <1>;
> > + compatible = "riscv,cpu-intc";
> > + interrupt-controller;
> > + };
> > + };
> > +
> > + cpu@2 {
> > + clock-frequency = <0>;
> > + compatible = "sifive,rocket0", "riscv";
> > + d-cache-block-size = <64>;
> > + d-cache-sets = <64>;
> > + d-cache-size = <32768>;
> > + d-tlb-sets = <1>;
> > + d-tlb-size = <32>;
> > + device_type = "cpu";
> > + i-cache-block-size = <64>;
> > + i-cache-sets = <64>;
> > + i-cache-size = <32768>;
> > + i-tlb-sets = <1>;
> > + i-tlb-size = <32>;
> > +
Re: [PATCH 00/12] dt-bindings: arm: fsl: fix and document compatibles
On Thu, Oct 01, 2020 at 07:07:47PM +0200, Krzysztof Kozlowski wrote: > Hi, > > This is a continuation of my series: > https://lore.kernel.org/linux-arm-kernel/20200930190143.27032-1-k...@kernel.org/ > > It is rebased on top of it and finally fixes remaining i.MX2 - i.MX8 > boards compatibles. > > There is ongoing discussion in my previous patchset about imx6q-pico > (Technexion) board compatibles so the DTS is marked as RFC. > > Best regards, > Krzysztof > > > Krzysztof Kozlowski (12): > dt-bindings: vendor-prefixes: add Element14 > dt-bindings: arm: fsl: document i.MX6Q boards > dt-bindings: arm: fsl: document i.MX6QP boards > dt-bindings: arm: fsl: document i.MX6SL boards > dt-bindings: arm: fsl: document i.MX6SX boards > dt-bindings: arm: fsl: document i.MX6UL boards > dt-bindings: arm: fsl: document i.MX6ULL boards > dt-bindings: arm: fsl: document i.MX7S boards This one doesn't apply ... > dt-bindings: arm: fsl: document i.MX7D boards > ARM: dts: imx6q-pico: fix board compatibles This one was applied from previous post ... > ARM: dts: imx6sl-warp: correct vendor in compatible to Revotics > ARM: dts: imx7s-warp: correct vendor in compatible to Element14 All others are applied. Shawn
Re: [Outreachy kernel] [PATCH] drm/amdgpu: use DEFINE_DEBUGFS_ATTRIBUTE with debugfs_create_file_unsafe()
On Fri, Oct 30, 2020 at 08:52:45AM +0530, Deepak R Varma wrote: > Using DEFINE_DEBUGFS_ATTRIBUTE macro with debugfs_create_file_unsafe() > function in place of the debugfs_create_file() function will make the > file operation struct "reset" aware of the file's lifetime. Additional > details here: https://lists.archive.carbon60.com/linux/kernel/2369498 > > Issue reported by Coccinelle script: > scripts/coccinelle/api/debugfs/debugfs_simple_attr.cocci > > Signed-off-by: Deepak R Varma > --- > Please Note: This is a Outreachy project task patch. > > drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 20 ++-- > 1 file changed, 10 insertions(+), 10 deletions(-) > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c > b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c > index 2d125b8b15ee..f076b1ba7319 100644 > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c > @@ -1551,29 +1551,29 @@ static int amdgpu_debugfs_sclk_set(void *data, u64 > val) > return 0; > } > > -DEFINE_SIMPLE_ATTRIBUTE(fops_ib_preempt, NULL, > - amdgpu_debugfs_ib_preempt, "%llu\n"); > +DEFINE_DEBUGFS_ATTRIBUTE(fops_ib_preempt, NULL, > + amdgpu_debugfs_ib_preempt, "%llu\n"); Are you sure this is ok? Do these devices need this additional "protection"? Do they have the problem that these macros were written for? Same for the other patches you just submitted here, I think you need to somehow "prove" that these changes are necessary, checkpatch isn't able to determine this all the time. thanks, greg k-h
Re: [PATCH 20/33] docs: ABI: testing: make the files compatible with ReST output
Em Thu, 29 Oct 2020 14:49:12 + Jonathan Cameron escreveu: > On Wed, 28 Oct 2020 15:23:18 +0100 > Mauro Carvalho Chehab wrote: > > > From: Mauro Carvalho Chehab > > > > Some files over there won't parse well by Sphinx. > > > > Fix them. > > > > Signed-off-by: Mauro Carvalho Chehab > > Signed-off-by: Mauro Carvalho Chehab > > Query below... I'm going to guess a rebase issue? Yes. I sent this series about 1,5 years ago. On that time, it ended by not being merged, as there were too much docs patches floating around. The second SoB is not there on my tree. It was added by git send-email ;-) Anyway, fixed. Thanks, Mauro
[PATCH] i40e: Fix memory leak in i40e_probe
Struct i40e_veb is allocated in function i40e_setup_pf_switch, and
stored to an array field veb inside struct i40e_pf. However when
i40e_setup_misc_vector fails, this memory leaks.
Fix this by calling exit and teardown functions.
Signed-off-by: Keita Suzuki
---
drivers/net/ethernet/intel/i40e/i40e_main.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c
b/drivers/net/ethernet/intel/i40e/i40e_main.c
index 4f8a2154b93f..428964c4ade1 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_main.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_main.c
@@ -15104,6 +15104,8 @@ static int i40e_probe(struct pci_dev *pdev, const
struct pci_device_id *ent)
if (err) {
dev_info(&pdev->dev,
"setup of misc vector failed: %d\n", err);
+ i40e_cloud_filter_exit(pf);
+ i40e_fdir_teardown(pf);
goto err_vsis;
}
}
--
2.17.1
[tip:x86/seves] BUILD SUCCESS 2411cd82112397bfb9d8f0f19cd46c3d71e0ce67
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86/seves branch HEAD: 2411cd82112397bfb9d8f0f19cd46c3d71e0ce67 x86/sev-es: Do not support MMIO to/from encrypted memory elapsed time: 721m configs tested: 135 configs skipped: 65 The following configs have been built successfully. More configs may be tested in the coming days. gcc tested configs: arm defconfig arm64allyesconfig arm64 defconfig arm allyesconfig arm allmodconfig h8300 h8s-sim_defconfig powerpcsocrates_defconfig powerpcklondike_defconfig mips pistachio_defconfig sh se7619_defconfig mips cobalt_defconfig sh rts7751r2d1_defconfig powerpc sequoia_defconfig powerpc tqm8555_defconfig arm am200epdkit_defconfig arm badge4_defconfig h8300 defconfig mipsqi_lb60_defconfig sh ul2_defconfig umkunit_defconfig openriscor1ksim_defconfig arm alldefconfig um x86_64_defconfig archsdk_defconfig mipsbcm47xx_defconfig m68k sun3_defconfig shmigor_defconfig microblaze mmu_defconfig arm corgi_defconfig sh kfr2r09_defconfig arm tct_hammer_defconfig xtensa audio_kc705_defconfig mips maltaaprp_defconfig powerpc mpc8540_ads_defconfig m68k m5475evb_defconfig shecovec24-romimage_defconfig powerpcgamecube_defconfig powerpc stx_gp3_defconfig powerpc maple_defconfig nds32 defconfig m68km5307c3_defconfig m68k m5208evb_defconfig mipsomega2p_defconfig powerpcwarp_defconfig sh sh7710voipgw_defconfig mips decstation_r4k_defconfig powerpc mpc8315_rdb_defconfig openrisc alldefconfig powerpc walnut_defconfig armmini2440_defconfig powerpc mpc837x_mds_defconfig armclps711x_defconfig riscvallyesconfig powerpc cm5200_defconfig mips rs90_defconfig armneponset_defconfig ia64 allmodconfig ia64defconfig ia64 allyesconfig m68k allmodconfig m68kdefconfig m68k allyesconfig nios2 defconfig arc allyesconfig nds32 allnoconfig c6x allyesconfig nios2allyesconfig cskydefconfig alpha defconfig alphaallyesconfig xtensa allyesconfig h8300allyesconfig arc defconfig sh allmodconfig parisc defconfig s390 allyesconfig parisc allyesconfig s390defconfig i386 allyesconfig sparcallyesconfig sparc defconfig i386defconfig mips allyesconfig mips allmodconfig powerpc allyesconfig powerpc allmodconfig powerpc allnoconfig x86_64 randconfig-a005-20201030 x86_64 randconfig-a001-20201030 x86_64 randconfig-a002-20201030 x86_64 randconfig-a003-20201030 x86_64 randconfig-a006-20201030 x86_64 randconfig-a004-20201030 i386 randconfig-a002-20201029 i386 randconfig-a005-20201029 i386 randconfig-a003-20201029 i386 randconfig-a001-20201029 i386 randconfig-a004-20201029 i386 randconfig-a006-20201029 i386 randconfig-a005-20201030 i386
Re: [PATCH] KVM: x86: Filter out more Intel-specific PMU MSRs in kvm_init_msr_list()
Vitaly Kuznetsov writes: > When running KVM selftest in a Hyper-V VM they stumble upon > > Unexpected result from KVM_GET_MSRS, r: 14 (failed MSR was 0x309) > > MSR_ARCH_PERFMON_FIXED_CTR[0..3] along with MSR_CORE_PERF_FIXED_CTR_CTRL, > MSR_CORE_PERF_GLOBAL_STATUS, MSR_CORE_PERF_GLOBAL_CTRL, > MSR_CORE_PERF_GLOBAL_OVF_CTRL are only valid for Intel PMU ver > 1 but > Hyper-V instances have CPUID.0AH.EAX == 0 (so perf code falls back to > p6_pmu instead of intel_pmu). Surprisingly, unlike on AMD hardware for > example, our rdmsr_safe() check passes and MSRs are not filtered out. > > MSR_ARCH_PERFMON_FIXED_CTR[0..3] can probably be checked against > x86_pmu.num_counters_fixed and the rest is only present with > x86_pmu.version > 1. > > Unfortunately, full elimination of the disconnection between system-wide > KVM_GET_MSR_INDEX_LIST/KVM_GET_MSR_FEATURE_INDEX_LIST and per-VCPU > KVM_GET_MSRS/KVM_SET_MSRS seem to be impossible as per-vCPU PMU setup > depends on guest CPUIDs which can always be altered. > > Signed-off-by: Vitaly Kuznetsov > --- > arch/x86/kvm/x86.c | 9 + > 1 file changed, 9 insertions(+) > > diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c > index ce856e0ece84..85d72b125fba 100644 > --- a/arch/x86/kvm/x86.c > +++ b/arch/x86/kvm/x86.c > @@ -5436,6 +5436,15 @@ static void kvm_init_msr_list(void) > min(INTEL_PMC_MAX_GENERIC, x86_pmu.num_counters_gp)) > continue; > break; > + case MSR_ARCH_PERFMON_FIXED_CTR0 ... > MSR_ARCH_PERFMON_FIXED_CTR0 + 3: > + if (msrs_to_save_all[i] - MSR_ARCH_PERFMON_FIXED_CTR0 >= > + min(INTEL_PMC_MAX_FIXED, > x86_pmu.num_counters_fixed)) > + continue; > + break; > + case MSR_CORE_PERF_FIXED_CTR_CTRL ... > MSR_CORE_PERF_GLOBAL_OVF_CTRL: > + if (x86_pmu.version <= 1) > + continue; > + break; > default: > break; > } Ping? -- Vitaly
Re: [PATCH 1/1] debugfs: Add a helper to export atomic64_t values
On Fri, Oct 30, 2020 at 06:04:42PM +1100, Anand K Mistry wrote:
> This mirrors support for exporting atomic_t values.
>
> Signed-off-by: Anand K Mistry
>
> ---
>
> fs/debugfs/file.c | 37 +
> include/linux/debugfs.h | 6 ++
> 2 files changed, 43 insertions(+)
>
> diff --git a/fs/debugfs/file.c b/fs/debugfs/file.c
> index a768a09430c3..798bd3bdedec 100644
> --- a/fs/debugfs/file.c
> +++ b/fs/debugfs/file.c
> @@ -770,6 +770,43 @@ void debugfs_create_atomic_t(const char *name, umode_t
> mode,
> }
> EXPORT_SYMBOL_GPL(debugfs_create_atomic_t);
>
> +static int debugfs_atomic64_t_set(void *data, u64 val)
> +{
> + atomic64_set((atomic64_t *)data, val);
> + return 0;
> +}
> +static int debugfs_atomic64_t_get(void *data, u64 *val)
> +{
> + *val = atomic64_read((atomic64_t *)data);
> + return 0;
> +}
> +DEFINE_DEBUGFS_ATTRIBUTE(fops_atomic64_t, debugfs_atomic64_t_get,
> + debugfs_atomic64_t_set, "%lld\n");
> +DEFINE_DEBUGFS_ATTRIBUTE(fops_atomic64_t_ro, debugfs_atomic64_t_get, NULL,
> + "%lld\n");
> +DEFINE_DEBUGFS_ATTRIBUTE(fops_atomic64_t_wo, NULL, debugfs_atomic64_t_set,
> + "%lld\n");
> +
> +/**
> + * debugfs_create_atomic64_t - create a debugfs file that is used to read and
> + * write an atomic64_t value
> + * @name: a pointer to a string containing the name of the file to create.
> + * @mode: the permission that the file should have
> + * @parent: a pointer to the parent dentry for this file. This should be a
> + * directory dentry if set. If this parameter is %NULL, then the
> + * file will be created in the root of the debugfs filesystem.
> + * @value: a pointer to the variable that the file should read to and write
> + * from.
> + */
> +void debugfs_create_atomic64_t(const char *name, umode_t mode,
> +struct dentry *parent, atomic64_t *value)
> +{
> + debugfs_create_mode_unsafe(name, mode, parent, value,
> +&fops_atomic64_t, &fops_atomic64_t_ro,
> +&fops_atomic64_t_wo);
> +}
> +EXPORT_SYMBOL_GPL(debugfs_create_atomic64_t);
> +
> ssize_t debugfs_read_file_bool(struct file *file, char __user *user_buf,
> size_t count, loff_t *ppos)
> {
> diff --git a/include/linux/debugfs.h b/include/linux/debugfs.h
> index 851dd1f9a8a5..0fac84c53eab 100644
> --- a/include/linux/debugfs.h
> +++ b/include/linux/debugfs.h
> @@ -126,6 +126,8 @@ void debugfs_create_size_t(const char *name, umode_t mode,
> struct dentry *parent, size_t *value);
> void debugfs_create_atomic_t(const char *name, umode_t mode,
>struct dentry *parent, atomic_t *value);
> +void debugfs_create_atomic64_t(const char *name, umode_t mode,
> + struct dentry *parent, atomic64_t *value);
> struct dentry *debugfs_create_bool(const char *name, umode_t mode,
> struct dentry *parent, bool *value);
>
> @@ -291,6 +293,10 @@ static inline void debugfs_create_atomic_t(const char
> *name, umode_t mode,
> atomic_t *value)
> { }
>
> +static inline void debugfs_create_atomic64_t(const char *name, umode_t mode,
> + struct dentry *parent, atomic64_t
> *value)
> +{ }
> +
> static inline struct dentry *debugfs_create_bool(const char *name, umode_t
> mode,
>struct dentry *parent,
>bool *value)
Looks good, but where is the user of this code? I can't add new apis
without a user.
And are you _SURE_ you want to be using an atomic64_t in the first
place? We are starting to reduce the "raw" usage of atomic variables as
almost no one needs them, they should be using something else instead,
or just a u64 as atomics are not needed for simple statistics.
thanks,
greg k-h
RE: Re: [PATCH v2 1/1] scsi: ufs: Fix unexpected values get from ufshcd_read_desc_param()
>> Hi, Can Guo
>>
>>> Since WB feature has been added, WB related sysfs entries can be
>>> accessed
>>> even when an UFS device does not support WB feature. In that case, the
>>> descriptors which are not supported by the UFS device may be wrongly
>>> reported when they are accessed from their corrsponding sysfs entries.
>>> Fix it by adding a sanity check of parameter offset against the actual
>>> decriptor length.
>>>
>>> Signed-off-by: Can Guo
>>> ---
>>> drivers/scsi/ufs/ufshcd.c | 24 +++-
>>> 1 file changed, 15 insertions(+), 9 deletions(-)
>>>
>>> diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
>>> index a2ebcc8..aeec10d 100644
>>> --- a/drivers/scsi/ufs/ufshcd.c
>>> +++ b/drivers/scsi/ufs/ufshcd.c
>>> @@ -3184,13 +3184,19 @@ int ufshcd_read_desc_param(struct ufs_hba
>>> *hba,
>>> /* Get the length of descriptor */
>>> ufshcd_map_desc_id_to_length(hba, desc_id, &buff_len);
>>> if (!buff_len) {
>>> - dev_err(hba->dev, "%s: Failed to get desc length", __func__);
>>> + dev_err(hba->dev, "%s: Failed to get desc length\n", __func__);
>>> + return -EINVAL;
>>> + }
>>> +
>>> + if (param_offset >= buff_len) {
>>> + dev_err(hba->dev, "%s: Invalid offset 0x%x in descriptor IDN
>>> 0x%x,
>>> length 0x%x\n",
>>> + __func__, param_offset, desc_id, buff_len);
>>
>> In my understanding, this code seems to check incorrect access to not
>> supportted features (e.g. WB) via buff_len value from
>> ufshcd_map_desc_id_to_length().
>> However, since buff_len is initialized as QUERY_DESC_MAX_SIZE and is
>> updated later by ufshcd_update_desc_length(), So it is impossible to
>> find
>> incorrect access by checking buff_len at first time.
>>
>> Thanks,
>> Daejun
>
>Yes, I considered that during bootup time, but the current driver won't
>even
>access WB related stuffs it is not supported (there are checks against
>UFS version
>and feature supports in ufshcd_wb_probe()). So this change is only
>proecting illegal
>access from sysfs entries after bootup is done. Do you see real error
>during bootup
>time? If yes, please let me know.
>
>Thanks,
>
>Can Guo.
Can Guo,
I haven't seen any real errors. If it's meant to prevent erroneous access
from sysfs, it seems good enough.
Acked-by: Daejun Park
Avri,
ufshcd_is_wb_attrs or ufshcd_is_wb_flag is used to match appropriate lun
in case of shared lu WB. I think Can Guo's code is suitable to prevent
wrong access to descriptors.
Thanks,
Daejun
Re: [PATCH] kunit: tool: fix extra trailing \n in parsed test output
On Fri, Oct 30, 2020 at 1:41 PM Daniel Latypov wrote:
>
> On Thu, Oct 29, 2020 at 7:34 PM David Gow wrote:
> >
> > On Wed, Oct 21, 2020 at 7:32 AM Daniel Latypov wrote:
> > >
> > > For simplcity, strip all trailing whitespace from parsed output.
> > > I imagine no one is printing out meaningful trailing whitespace via
> > > KUNIT_FAIL() or similar, and that if they are, they really shouldn't.
> > >
> > > At some point, the lines from `isolate_kunit_output()` started having
> > > trailing \n, which results in artifacty output like this:
> > >
> > > $ ./tools/testing/kunit/kunit.py run
> > > [16:16:46] [FAILED] example_simple_test
> > > [16:16:46] # example_simple_test: EXPECTATION FAILED at
> > > lib/kunit/kunit-example-test.c:29
> > >
> > > [16:16:46] Expected 1 + 1 == 3, but
> > >
> > > [16:16:46] 1 + 1 == 2
> > >
> > > [16:16:46] 3 == 3
> > >
> > > [16:16:46] not ok 1 - example_simple_test
> > >
> > > [16:16:46]
> > >
> > > After this change:
> > > [16:16:46] # example_simple_test: EXPECTATION FAILED at
> > > lib/kunit/kunit-example-test.c:29
> > > [16:16:46] Expected 1 + 1 == 3, but
> > > [16:16:46] 1 + 1 == 2
> > > [16:16:46] 3 == 3
> > > [16:16:46] not ok 1 - example_simple_test
> > > [16:16:46]
> > >
> > > Signed-off-by: Daniel Latypov
> > > ---
> >
> > Thanks! This is a long-overdue fix, and it worked well for me.
> >
> > Tested-by: David Gow
> >
> > One comment below:
> >
> > > tools/testing/kunit/kunit_parser.py | 3 ++-
> > > 1 file changed, 2 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/tools/testing/kunit/kunit_parser.py
> > > b/tools/testing/kunit/kunit_parser.py
> > > index 8019e3dd4c32..e68b1c66a73f 100644
> > > --- a/tools/testing/kunit/kunit_parser.py
> > > +++ b/tools/testing/kunit/kunit_parser.py
> > > @@ -342,7 +342,8 @@ def parse_run_tests(kernel_output) -> TestResult:
> > > total_tests = 0
> > > failed_tests = 0
> > > crashed_tests = 0
> > > - test_result =
> > > parse_test_result(list(isolate_kunit_output(kernel_output)))
> > > + test_result = parse_test_result(list(
> > > +l.rstrip() for l in isolate_kunit_output(kernel_output)))
> >
> > Could we do this inside isolate_kunit_output() instead? That seems
> > like it'd be a more logical place for it (removing the newline is a
> > sort of isolating the output), and it'd avoid making this line quite
> > as horrifyingly nested.
>
> Good point.
> We could either do it on each yield (messy), or before, i.e.
>
> diff --git a/tools/testing/kunit/kunit_parser.py
> b/tools/testing/kunit/kunit_parser.py
> index 8019e3dd4c32..14d35deb96cd 100644
> --- a/tools/testing/kunit/kunit_parser.py
> +++ b/tools/testing/kunit/kunit_parser.py
> @@ -54,6 +54,7 @@ kunit_end_re = re.compile('(List of all partitions:|'
> def isolate_kunit_output(kernel_output):
> started = False
> for line in kernel_output:
> + line = line.rstrip() # line always has a trailing \n
> if kunit_start_re.search(line):
> prefix_len = len(line.split('TAP version')[0])
> started = True
>
> I had some vague concerns about this as
> kunit_start_re = re.compile(r'TAP version [0-9]+$')
> has that anchor at the end.
>
> This could ostensibly make it match more things than before.
> Since I'm using rstrip() out of laziness, that means strings like
> 'TAP version 42\t\n'
> will now also match.
>
> I don't really think that's an issue, but I'd sent this as a more
> conservative change initially.
> I can send the diff above as a replacement for this patch.
I prefer this if it works. From my cursory testing, it does (though
the kunt_tool_tests.py tests will need updating). At the very least,
I'm able to get it to work with --alltests / allyesconfig (with a few
options tactically disabled), which was the main reason we needed
isolate_kunit_output() in the first place.
So, unless anyone can find a real-world case where this breaks
something, let's go with this.
Cheers,
-- David
>
> >
> > > if test_result.status == TestStatus.NO_TESTS:
> > > print(red('[ERROR] ') + yellow('no tests run!'))
> > > elif test_result.status == TestStatus.FAILURE_TO_PARSE_TESTS:
> > >
> > > base-commit: c4d6fe7311762f2e03b3c27ad38df7c40c80cc93
> > > --
> > > 2.29.0.rc1.297.gfa9743e501-goog
> > >
Re: [PATCH] kunit: tool: fix --raw_output to actually show output
On Fri, Oct 30, 2020 at 2:17 PM Daniel Latypov wrote: > > Currently --raw_output means nothing gets shown. > Why? > Because `raw_output()` has a `yield` and therefore is a generator, which > means it only executes when you ask it for a value. > > Given no one actually is using it as a generator (checked via the added > type annotation), drop the yield so we actually print the output. > > Also strip off the trailing \n (and any other whitespace) to avoid > [<601d6d3a>] ? printk+0x0/0x9b > > [<601e5058>] ? kernel_init+0x23/0x14b > > [<600170d2>] ? new_thread_handler+0x82/0xc0 > making the output unreadable. > > Signed-off-by: Daniel Latypov > --- The bug where --raw_output doesn't show anything is already fixed[1], but it does still show the extra newlines. Maybe it's worth making just the newline fix, and rolling it into the other patch[2] handling newlines? Cheers, -- David [1]: https://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest.git/commit/?h=kunit-fixes&id=3023d8ff3fc60e5d32dc1d05f99ad6ffa12b0033 [2]: https://lore.kernel.org/linux-kselftest/20201020233219.4146059-1-dlaty...@google.com/
[PATCH] spi: sprd: add runtime pm for transfer message
From: Bangzheng Liu
Before transfer one message, spi core would set chipselect, sprd spi
device should be resumed from runtime suspend, otherwise kernel would
crash once access spi registers. The sprd spi device can be suspended
until clearing chipselect which would be executed after transfer.
Fixes: e7d973a31c24 ("spi: sprd: Add SPI driver for Spreadtrum SC9860")
Signed-off-by: Bangzheng Liu
Signed-off-by: Chunyan Zhang
---
drivers/spi/spi-sprd.c | 16 +---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/drivers/spi/spi-sprd.c b/drivers/spi/spi-sprd.c
index 635738f54c73..1733d10eb296 100644
--- a/drivers/spi/spi-sprd.c
+++ b/drivers/spi/spi-sprd.c
@@ -293,15 +293,25 @@ static void sprd_spi_chipselect(struct spi_device *sdev,
bool cs)
struct spi_controller *sctlr = sdev->controller;
struct sprd_spi *ss = spi_controller_get_devdata(sctlr);
u32 val;
+ int ret;
- val = readl_relaxed(ss->base + SPRD_SPI_CTL0);
/* The SPI controller will pull down CS pin if cs is 0 */
if (!cs) {
- val &= ~SPRD_SPI_CS0_VALID;
+ ret = pm_runtime_get_sync(ss->dev);
+ if (ret < 0) {
+ pm_runtime_put_noidle(ss->dev);
+ dev_err(ss->dev, "Failed to power device: %d\n", ret);
+ return;
+ }
+ val = readl_relaxed(ss->base + SPRD_SPI_CTL0);
+ val &= ~SPRD_SPI_CS0_VALID; /* set cs0 valid */
writel_relaxed(val, ss->base + SPRD_SPI_CTL0);
} else {
- val |= SPRD_SPI_CSN_MASK;
+ val = readl_relaxed(ss->base + SPRD_SPI_CTL0);
+ val |= SPRD_SPI_CSN_MASK; /* set all cs invalid */
writel_relaxed(val, ss->base + SPRD_SPI_CTL0);
+ pm_runtime_mark_last_busy(ss->dev);
+ pm_runtime_put_autosuspend(ss->dev);
}
}
--
2.20.1
Re: [patch V2 00/18] mm/highmem: Preemptible variant of kmap_atomic & friends
On Thu, Oct 29, 2020 at 11:18:06PM +0100, Thomas Gleixner wrote: > This is achieved by: ... > > - Consolidating all kmap atomic implementations in generic code ... > Though I wanted to share the current state of affairs before investigating > that further. If there is consensus in going forward with this, I'll have a > deeper look into this issue. I think the consolidation is a winner no matter where we go next. Maybe split it out in a prep series so we can get it in ASAP?
[PATCH v2] f2fs: move ioctl interface definitions to separated file
Like other filesystem does, we introduce a new file f2fs.h in path of
include/uapi/linux/, and move f2fs-specified ioctl interface definitions
to that file, after then, in order to use those definitions, userspace
developer only need to include the new header file rather than
copy & paste definitions from fs/f2fs/f2fs.h.
Signed-off-by: Chao Yu
---
v2: add missing "WITH Linux-syscall-note" for SPDX-License-Identifier
MAINTAINERS | 1 +
fs/f2fs/f2fs.h | 79 --
fs/f2fs/file.c | 1 +
include/trace/events/f2fs.h | 1 +
include/uapi/linux/f2fs.h | 86 +
5 files changed, 89 insertions(+), 79 deletions(-)
create mode 100644 include/uapi/linux/f2fs.h
diff --git a/MAINTAINERS b/MAINTAINERS
index d1d4e49a695a..b79a911f1e32 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6686,6 +6686,7 @@ F:Documentation/filesystems/f2fs.rst
F: fs/f2fs/
F: include/linux/f2fs_fs.h
F: include/trace/events/f2fs.h
+F: include/uapi/linux/f2fs.h
F71805F HARDWARE MONITORING DRIVER
M: Jean Delvare
diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index cb700d797296..99bcf4b44a9c 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -402,85 +402,6 @@ static inline bool __has_cursum_space(struct f2fs_journal
*journal,
return size <= MAX_SIT_JENTRIES(journal);
}
-/*
- * f2fs-specific ioctl commands
- */
-#define F2FS_IOCTL_MAGIC 0xf5
-#define F2FS_IOC_START_ATOMIC_WRITE_IO(F2FS_IOCTL_MAGIC, 1)
-#define F2FS_IOC_COMMIT_ATOMIC_WRITE _IO(F2FS_IOCTL_MAGIC, 2)
-#define F2FS_IOC_START_VOLATILE_WRITE _IO(F2FS_IOCTL_MAGIC, 3)
-#define F2FS_IOC_RELEASE_VOLATILE_WRITE_IO(F2FS_IOCTL_MAGIC, 4)
-#define F2FS_IOC_ABORT_VOLATILE_WRITE _IO(F2FS_IOCTL_MAGIC, 5)
-#define F2FS_IOC_GARBAGE_COLLECT _IOW(F2FS_IOCTL_MAGIC, 6, __u32)
-#define F2FS_IOC_WRITE_CHECKPOINT _IO(F2FS_IOCTL_MAGIC, 7)
-#define F2FS_IOC_DEFRAGMENT_IOWR(F2FS_IOCTL_MAGIC, 8, \
- struct f2fs_defragment)
-#define F2FS_IOC_MOVE_RANGE_IOWR(F2FS_IOCTL_MAGIC, 9, \
- struct f2fs_move_range)
-#define F2FS_IOC_FLUSH_DEVICE _IOW(F2FS_IOCTL_MAGIC, 10, \
- struct f2fs_flush_device)
-#define F2FS_IOC_GARBAGE_COLLECT_RANGE _IOW(F2FS_IOCTL_MAGIC, 11, \
- struct f2fs_gc_range)
-#define F2FS_IOC_GET_FEATURES _IOR(F2FS_IOCTL_MAGIC, 12, __u32)
-#define F2FS_IOC_SET_PIN_FILE _IOW(F2FS_IOCTL_MAGIC, 13, __u32)
-#define F2FS_IOC_GET_PIN_FILE _IOR(F2FS_IOCTL_MAGIC, 14, __u32)
-#define F2FS_IOC_PRECACHE_EXTENTS _IO(F2FS_IOCTL_MAGIC, 15)
-#define F2FS_IOC_RESIZE_FS _IOW(F2FS_IOCTL_MAGIC, 16, __u64)
-#define F2FS_IOC_GET_COMPRESS_BLOCKS _IOR(F2FS_IOCTL_MAGIC, 17, __u64)
-#define F2FS_IOC_RELEASE_COMPRESS_BLOCKS \
- _IOR(F2FS_IOCTL_MAGIC, 18, __u64)
-#define F2FS_IOC_RESERVE_COMPRESS_BLOCKS \
- _IOR(F2FS_IOCTL_MAGIC, 19, __u64)
-#define F2FS_IOC_SEC_TRIM_FILE _IOW(F2FS_IOCTL_MAGIC, 20, \
- struct f2fs_sectrim_range)
-
-/*
- * should be same as XFS_IOC_GOINGDOWN.
- * Flags for going down operation used by FS_IOC_GOINGDOWN
- */
-#define F2FS_IOC_SHUTDOWN _IOR('X', 125, __u32) /* Shutdown */
-#define F2FS_GOING_DOWN_FULLSYNC 0x0 /* going down with full sync */
-#define F2FS_GOING_DOWN_METASYNC 0x1 /* going down with metadata */
-#define F2FS_GOING_DOWN_NOSYNC 0x2 /* going down */
-#define F2FS_GOING_DOWN_METAFLUSH 0x3 /* going down with meta flush */
-#define F2FS_GOING_DOWN_NEED_FSCK 0x4 /* going down to trigger fsck */
-
-/*
- * Flags used by F2FS_IOC_SEC_TRIM_FILE
- */
-#define F2FS_TRIM_FILE_DISCARD 0x1 /* send discard command */
-#define F2FS_TRIM_FILE_ZEROOUT 0x2 /* zero out */
-#define F2FS_TRIM_FILE_MASK0x3
-
-struct f2fs_gc_range {
- u32 sync;
- u64 start;
- u64 len;
-};
-
-struct f2fs_defragment {
- u64 start;
- u64 len;
-};
-
-struct f2fs_move_range {
- u32 dst_fd; /* destination fd */
- u64 pos_in; /* start position in src_fd */
- u64 pos_out;/* start position in dst_fd */
- u64 len;/* size to move */
-};
-
-struct f2fs_flush_device {
- u32 dev_num;/* device number to flush */
- u32 segments; /* # of segments to flush */
-};
-
-struct f2fs_sectrim_range {
- u64 start;
- u64 len;
- u64 flags;
-};
-
/* for inline stuff */
#define DEF_INLINE_RESERVED_SIZE 1
static inline int get_extra_isize(struct
Re: [PATCH -V2 1/2] mempolicy: Rename MPOL_F_MORON to MPOL_F_MOPRON
Michal Hocko writes:
> On Wed 28-10-20 10:34:10, Huang Ying wrote:
>> To follow code-of-conduct better.
>
> This is changing a user visible interface and any userspace which refers
> to the existing name will fail to compile unless I am missing something.
Although these flags are put in uapi, I found these flags are actually
internal flags used in "flags" field of struct mempolicy, they are never
used as flags for any user space API. I guess they are placed in uapi
header file to guarantee they aren't conflict with MPOL_MODE_FLAGS.
> Have you checked how many applications would be affected?
Based on above analysis, I think there is no application that will be
affected.
> Btw I find "follow CoC better" a very weak argument without further
> explanation.
That is the only reason for the patch. If nobody thinks the change is
necessary, I can just drop the patch.
Best Regards,
Huang, Ying
>> Signed-off-by: "Huang, Ying"
>> Suggested-by: "Matthew Wilcox (Oracle)"
>> Acked-by: Rafael Aquini
>> Cc: Andrew Morton
>> Cc: Ingo Molnar
>> Cc: Mel Gorman
>> Cc: Rik van Riel
>> Cc: Johannes Weiner
>> Cc: Dave Hansen
>> Cc: Andi Kleen
>> Cc: Michal Hocko
>> Cc: David Rientjes
>> Cc: Rafael Aquini
>> ---
>> include/uapi/linux/mempolicy.h | 2 +-
>> kernel/sched/debug.c | 2 +-
>> mm/mempolicy.c | 6 +++---
>> 3 files changed, 5 insertions(+), 5 deletions(-)
>>
>> diff --git a/include/uapi/linux/mempolicy.h b/include/uapi/linux/mempolicy.h
>> index 3354774af61e..3c3666d017e6 100644
>> --- a/include/uapi/linux/mempolicy.h
>> +++ b/include/uapi/linux/mempolicy.h
>> @@ -60,7 +60,7 @@ enum {
>> #define MPOL_F_SHARED (1 << 0) /* identify shared policies */
>> #define MPOL_F_LOCAL (1 << 1) /* preferred local allocation */
>> #define MPOL_F_MOF (1 << 3) /* this policy wants migrate on fault */
>> -#define MPOL_F_MORON(1 << 4) /* Migrate On protnone Reference On
>> Node */
>> +#define MPOL_F_MOPRON (1 << 4) /* Migrate On Protnone Reference On
>> Node */
>>
>>
>> #endif /* _UAPI_LINUX_MEMPOLICY_H */
>> diff --git a/kernel/sched/debug.c b/kernel/sched/debug.c
>> index 0655524700d2..8bfb6adb3f31 100644
>> --- a/kernel/sched/debug.c
>> +++ b/kernel/sched/debug.c
>> @@ -898,7 +898,7 @@ static void sched_show_numa(struct task_struct *p,
>> struct seq_file *m)
>>
>> task_lock(p);
>> pol = p->mempolicy;
>> -if (pol && !(pol->flags & MPOL_F_MORON))
>> +if (pol && !(pol->flags & MPOL_F_MOPRON))
>> pol = NULL;
>> mpol_get(pol);
>> task_unlock(p);
>> diff --git a/mm/mempolicy.c b/mm/mempolicy.c
>> index 3fde772ef5ef..f6948b659643 100644
>> --- a/mm/mempolicy.c
>> +++ b/mm/mempolicy.c
>> @@ -2511,7 +2511,7 @@ int mpol_misplaced(struct page *page, struct
>> vm_area_struct *vma, unsigned long
>> }
>>
>> /* Migrate the page towards the node whose CPU is referencing it */
>> -if (pol->flags & MPOL_F_MORON) {
>> +if (pol->flags & MPOL_F_MOPRON) {
>> polnid = thisnid;
>>
>> if (!should_numa_migrate_memory(current, page, curnid, thiscpu))
>> @@ -2802,7 +2802,7 @@ void __init numa_policy_init(void)
>> preferred_node_policy[nid] = (struct mempolicy) {
>> .refcnt = ATOMIC_INIT(1),
>> .mode = MPOL_PREFERRED,
>> -.flags = MPOL_F_MOF | MPOL_F_MORON,
>> +.flags = MPOL_F_MOF | MPOL_F_MOPRON,
>> .v = { .preferred_node = nid, },
>> };
>> }
>> @@ -3010,7 +3010,7 @@ void mpol_to_str(char *buffer, int maxlen, struct
>> mempolicy *pol)
>> unsigned short mode = MPOL_DEFAULT;
>> unsigned short flags = 0;
>>
>> -if (pol && pol != &default_policy && !(pol->flags & MPOL_F_MORON)) {
>> +if (pol && pol != &default_policy && !(pol->flags & MPOL_F_MOPRON)) {
>> mode = pol->mode;
>> flags = pol->flags;
>> }
>> --
>> 2.28.0
>>
Re: [PATCH v4 2/2] firmware: QCOM_SCM: Allow qcom_scm driver to be loadable as a permenent module
> diff --git a/drivers/net/wireless/ath/ath10k/Kconfig > b/drivers/net/wireless/ath/ath10k/Kconfig > index 40f91bc8514d8..a490e78890017 100644 > --- a/drivers/net/wireless/ath/ath10k/Kconfig > +++ b/drivers/net/wireless/ath/ath10k/Kconfig > @@ -44,6 +44,7 @@ config ATH10K_SNOC > tristate "Qualcomm ath10k SNOC support" > depends on ATH10K > depends on ARCH_QCOM || COMPILE_TEST > + depends on QCOM_QCM || !QCOM_SCM #if QCOM_SCM=m this can't be =y Doh. Apologies! I flubbed this line (SCM not QCM). I'll fix and resend tomorrow. thanks -john
[PATCH] cpufreq: schedutil: Don't skip freq update if need_freq_update is set
The cpufreq policy's frequency limits (min/max) can get changed at any
point of time, while schedutil is trying to update the next frequency.
Though the schedutil governor has necessary locking and support in place
to make sure we don't miss any of those updates, there is a corner case
where the governor will find that the CPU is already running at the
desired frequency and so may skip an update.
For example, consider that the CPU can run at 1 GHz, 1.2 GHz and 1.4 GHz
and is running at 1 GHz currently. Schedutil tries to update the
frequency to 1.2 GHz, during this time the policy limits get changed as
policy->min = 1.4 GHz. As schedutil (and cpufreq core) does clamp the
frequency at various instances, we will eventually set the frequency to
1.4 GHz, while we will save 1.2 GHz in sg_policy->next_freq.
Now lets say the policy limits get changed back at this time with
policy->min as 1 GHz. The next time schedutil is invoked by the
scheduler, we will reevaluate the next frequency (because
need_freq_update will get set due to limits change event) and lets say
we want to set the frequency to 1.2 GHz again. At this point
sugov_update_next_freq() will find the next_freq == current_freq and
will abort the update, while the CPU actually runs at 1.4 GHz.
Until now need_freq_update was used as a flag to indicate that the
policy's frequency limits have changed, and that we should consider the
new limits while reevaluating the next frequency.
This patch fixes the above mentioned issue by extending the purpose of
the need_freq_update flag. If this flag is set now, the schedutil
governor will not try to abort a frequency change even if next_freq ==
current_freq.
As similar behavior is required in the case of
CPUFREQ_NEED_UPDATE_LIMITS flag as well, need_freq_update will never be
set to false if that flag is set for the driver.
We also don't need to consider the need_freq_update flag in
sugov_update_single() anymore to handle the special case of busy CPU, as
we won't abort a frequency update anymore.
Reported-by: zhuguangqing
Suggested-by: Rafael J. Wysocki
Signed-off-by: Viresh Kumar
---
kernel/sched/cpufreq_schedutil.c | 22 ++
1 file changed, 10 insertions(+), 12 deletions(-)
diff --git a/kernel/sched/cpufreq_schedutil.c b/kernel/sched/cpufreq_schedutil.c
index c03a5775d019..c6861be02c86 100644
--- a/kernel/sched/cpufreq_schedutil.c
+++ b/kernel/sched/cpufreq_schedutil.c
@@ -102,9 +102,12 @@ static bool sugov_should_update_freq(struct sugov_policy
*sg_policy, u64 time)
static bool sugov_update_next_freq(struct sugov_policy *sg_policy, u64 time,
unsigned int next_freq)
{
- if (sg_policy->next_freq == next_freq &&
- !cpufreq_driver_test_flags(CPUFREQ_NEED_UPDATE_LIMITS))
- return false;
+ if (!sg_policy->need_freq_update) {
+ if (sg_policy->next_freq == next_freq)
+ return false;
+ } else if (!cpufreq_driver_test_flags(CPUFREQ_NEED_UPDATE_LIMITS)) {
+ sg_policy->need_freq_update = false;
+ }
sg_policy->next_freq = next_freq;
sg_policy->last_freq_update_time = time;
@@ -162,11 +165,9 @@ static unsigned int get_next_freq(struct sugov_policy
*sg_policy,
freq = map_util_freq(util, freq, max);
- if (freq == sg_policy->cached_raw_freq && !sg_policy->need_freq_update
&&
- !cpufreq_driver_test_flags(CPUFREQ_NEED_UPDATE_LIMITS))
+ if (freq == sg_policy->cached_raw_freq && !sg_policy->need_freq_update)
return sg_policy->next_freq;
- sg_policy->need_freq_update = false;
sg_policy->cached_raw_freq = freq;
return cpufreq_driver_resolve_freq(policy, freq);
}
@@ -442,7 +443,6 @@ static void sugov_update_single(struct update_util_data
*hook, u64 time,
struct sugov_policy *sg_policy = sg_cpu->sg_policy;
unsigned long util, max;
unsigned int next_f;
- bool busy;
unsigned int cached_freq = sg_policy->cached_raw_freq;
sugov_iowait_boost(sg_cpu, time, flags);
@@ -453,9 +453,6 @@ static void sugov_update_single(struct update_util_data
*hook, u64 time,
if (!sugov_should_update_freq(sg_policy, time))
return;
- /* Limits may have changed, don't skip frequency update */
- busy = !sg_policy->need_freq_update && sugov_cpu_is_busy(sg_cpu);
-
util = sugov_get_util(sg_cpu);
max = sg_cpu->max;
util = sugov_iowait_apply(sg_cpu, time, util, max);
@@ -464,7 +461,7 @@ static void sugov_update_single(struct update_util_data
*hook, u64 time,
* Do not reduce the frequency if the CPU has not been idle
* recently, as the reduction is likely to be premature then.
*/
- if (busy && next_f < sg_policy->next_freq) {
+ if (sugov_cpu_is_busy(sg_cpu) && next_f < sg_policy->next_freq) {
next_f = sg_policy->next_freq;
/* Restore c
Re: [PATCH 1/1] debugfs: Add a helper to export atomic64_t values
On Fri, 30 Oct 2020 at 18:20, Greg Kroah-Hartman
wrote:
>
> On Fri, Oct 30, 2020 at 06:04:42PM +1100, Anand K Mistry wrote:
> > This mirrors support for exporting atomic_t values.
> >
> > Signed-off-by: Anand K Mistry
> >
> > ---
> >
> > fs/debugfs/file.c | 37 +
> > include/linux/debugfs.h | 6 ++
> > 2 files changed, 43 insertions(+)
> >
> > diff --git a/fs/debugfs/file.c b/fs/debugfs/file.c
> > index a768a09430c3..798bd3bdedec 100644
> > --- a/fs/debugfs/file.c
> > +++ b/fs/debugfs/file.c
> > @@ -770,6 +770,43 @@ void debugfs_create_atomic_t(const char *name, umode_t
> > mode,
> > }
> > EXPORT_SYMBOL_GPL(debugfs_create_atomic_t);
> >
> > +static int debugfs_atomic64_t_set(void *data, u64 val)
> > +{
> > + atomic64_set((atomic64_t *)data, val);
> > + return 0;
> > +}
> > +static int debugfs_atomic64_t_get(void *data, u64 *val)
> > +{
> > + *val = atomic64_read((atomic64_t *)data);
> > + return 0;
> > +}
> > +DEFINE_DEBUGFS_ATTRIBUTE(fops_atomic64_t, debugfs_atomic64_t_get,
> > + debugfs_atomic64_t_set, "%lld\n");
> > +DEFINE_DEBUGFS_ATTRIBUTE(fops_atomic64_t_ro, debugfs_atomic64_t_get, NULL,
> > + "%lld\n");
> > +DEFINE_DEBUGFS_ATTRIBUTE(fops_atomic64_t_wo, NULL, debugfs_atomic64_t_set,
> > + "%lld\n");
> > +
> > +/**
> > + * debugfs_create_atomic64_t - create a debugfs file that is used to read
> > and
> > + * write an atomic64_t value
> > + * @name: a pointer to a string containing the name of the file to create.
> > + * @mode: the permission that the file should have
> > + * @parent: a pointer to the parent dentry for this file. This should be a
> > + * directory dentry if set. If this parameter is %NULL, then the
> > + * file will be created in the root of the debugfs filesystem.
> > + * @value: a pointer to the variable that the file should read to and write
> > + * from.
> > + */
> > +void debugfs_create_atomic64_t(const char *name, umode_t mode,
> > +struct dentry *parent, atomic64_t *value)
> > +{
> > + debugfs_create_mode_unsafe(name, mode, parent, value,
> > +&fops_atomic64_t, &fops_atomic64_t_ro,
> > +&fops_atomic64_t_wo);
> > +}
> > +EXPORT_SYMBOL_GPL(debugfs_create_atomic64_t);
> > +
> > ssize_t debugfs_read_file_bool(struct file *file, char __user *user_buf,
> > size_t count, loff_t *ppos)
> > {
> > diff --git a/include/linux/debugfs.h b/include/linux/debugfs.h
> > index 851dd1f9a8a5..0fac84c53eab 100644
> > --- a/include/linux/debugfs.h
> > +++ b/include/linux/debugfs.h
> > @@ -126,6 +126,8 @@ void debugfs_create_size_t(const char *name, umode_t
> > mode,
> > struct dentry *parent, size_t *value);
> > void debugfs_create_atomic_t(const char *name, umode_t mode,
> >struct dentry *parent, atomic_t *value);
> > +void debugfs_create_atomic64_t(const char *name, umode_t mode,
> > + struct dentry *parent, atomic64_t
> > *value);
> > struct dentry *debugfs_create_bool(const char *name, umode_t mode,
> > struct dentry *parent, bool *value);
> >
> > @@ -291,6 +293,10 @@ static inline void debugfs_create_atomic_t(const char
> > *name, umode_t mode,
> > atomic_t *value)
> > { }
> >
> > +static inline void debugfs_create_atomic64_t(const char *name, umode_t
> > mode,
> > + struct dentry *parent,
> > atomic64_t *value)
> > +{ }
> > +
> > static inline struct dentry *debugfs_create_bool(const char *name, umode_t
> > mode,
> >struct dentry *parent,
> >bool *value)
>
> Looks good, but where is the user of this code? I can't add new apis
> without a user.
Fair enough. Right now, the user is just some local
debugging/performance measuring which will never be upstreamed.
Happy to let this drop.
>
> And are you _SURE_ you want to be using an atomic64_t in the first
> place? We are starting to reduce the "raw" usage of atomic variables as
> almost no one needs them, they should be using something else instead,
> or just a u64 as atomics are not needed for simple statistics.
I understand, and would generally never use atomics in real code. I
used an atomic since I wanted accuracy
(for some of the benchmarks I want to run) but can't use anything that
blocks (spinlock/mutex) since
the code is somewhere inside the scheduler.
>
> thanks,
>
> greg k-h
--
Anand K. Mistry
Software Engineer
Google Australia
Re: [PATCH v2 net] net: sch_generic: aviod concurrent reset and enqueue op for lockless qdisc
On 2020/10/30 3:05, Cong Wang wrote:
> On Wed, Oct 28, 2020 at 7:54 PM Yunsheng Lin wrote:
>>
>> On 2020/9/18 3:26, Cong Wang wrote:
>>> On Fri, Sep 11, 2020 at 1:13 AM Yunsheng Lin wrote:
On 2020/9/11 4:07, Cong Wang wrote:
> On Tue, Sep 8, 2020 at 4:06 AM Yunsheng Lin
> wrote:
>>
>> Currently there is concurrent reset and enqueue operation for the
>> same lockless qdisc when there is no lock to synchronize the
>> q->enqueue() in __dev_xmit_skb() with the qdisc reset operation in
>> qdisc_deactivate() called by dev_deactivate_queue(), which may cause
>> out-of-bounds access for priv->ring[] in hns3 driver if user has
>> requested a smaller queue num when __dev_xmit_skb() still enqueue a
>> skb with a larger queue_mapping after the corresponding qdisc is
>> reset, and call hns3_nic_net_xmit() with that skb later.
>>
>> Reused the existing synchronize_net() in dev_deactivate_many() to
>> make sure skb with larger queue_mapping enqueued to old qdisc(which
>> is saved in dev_queue->qdisc_sleeping) will always be reset when
>> dev_reset_queue() is called.
>>
>> Fixes: 6b3ba9146fe6 ("net: sched: allow qdiscs to handle locking")
>> Signed-off-by: Yunsheng Lin
>> ---
>> ChangeLog V2:
>> Reuse existing synchronize_net().
>> ---
>> net/sched/sch_generic.c | 48
>> +---
>> 1 file changed, 33 insertions(+), 15 deletions(-)
>>
>> diff --git a/net/sched/sch_generic.c b/net/sched/sch_generic.c
>> index 265a61d..54c4172 100644
>> --- a/net/sched/sch_generic.c
>> +++ b/net/sched/sch_generic.c
>> @@ -1131,24 +1131,10 @@ EXPORT_SYMBOL(dev_activate);
>>
>> static void qdisc_deactivate(struct Qdisc *qdisc)
>> {
>> - bool nolock = qdisc->flags & TCQ_F_NOLOCK;
>> -
>> if (qdisc->flags & TCQ_F_BUILTIN)
>> return;
>> - if (test_bit(__QDISC_STATE_DEACTIVATED, &qdisc->state))
>> - return;
>> -
>> - if (nolock)
>> - spin_lock_bh(&qdisc->seqlock);
>> - spin_lock_bh(qdisc_lock(qdisc));
>>
>> set_bit(__QDISC_STATE_DEACTIVATED, &qdisc->state);
>> -
>> - qdisc_reset(qdisc);
>> -
>> - spin_unlock_bh(qdisc_lock(qdisc));
>> - if (nolock)
>> - spin_unlock_bh(&qdisc->seqlock);
>> }
>>
>> static void dev_deactivate_queue(struct net_device *dev,
>> @@ -1165,6 +1151,30 @@ static void dev_deactivate_queue(struct
>> net_device *dev,
>> }
>> }
>>
>> +static void dev_reset_queue(struct net_device *dev,
>> + struct netdev_queue *dev_queue,
>> + void *_unused)
>> +{
>> + struct Qdisc *qdisc;
>> + bool nolock;
>> +
>> + qdisc = dev_queue->qdisc_sleeping;
>> + if (!qdisc)
>> + return;
>> +
>> + nolock = qdisc->flags & TCQ_F_NOLOCK;
>> +
>> + if (nolock)
>> + spin_lock_bh(&qdisc->seqlock);
>> + spin_lock_bh(qdisc_lock(qdisc));
>
>
> I think you do not need this lock for lockless one.
It seems so.
Maybe another patch to remove qdisc_lock(qdisc) for lockless
qdisc?
>>>
>>> Yeah, but not sure if we still want this lockless qdisc any more,
>>> it brings more troubles than gains.
>>>
>
>> +
>> + qdisc_reset(qdisc);
>> +
>> + spin_unlock_bh(qdisc_lock(qdisc));
>> + if (nolock)
>> + spin_unlock_bh(&qdisc->seqlock);
>> +}
>> +
>> static bool some_qdisc_is_busy(struct net_device *dev)
>> {
>> unsigned int i;
>> @@ -1213,12 +1223,20 @@ void dev_deactivate_many(struct list_head *head)
>> dev_watchdog_down(dev);
>> }
>>
>> - /* Wait for outstanding qdisc-less dev_queue_xmit calls.
>> + /* Wait for outstanding qdisc-less dev_queue_xmit calls or
>> +* outstanding qdisc enqueuing calls.
>> * This is avoided if all devices are in dismantle phase :
>> * Caller will call synchronize_net() for us
>> */
>> synchronize_net();
>>
>> + list_for_each_entry(dev, head, close_list) {
>> + netdev_for_each_tx_queue(dev, dev_reset_queue, NULL);
>> +
>> + if (dev_ingress_queue(dev))
>> + dev_reset_queue(dev, dev_ingress_queue(dev),
>> NULL);
>> + }
>> +
>> /* Wait for outstanding qdisc_run calls. */
>> list_for_each_entry(dev, head, close_list) {
>> while (some_qdisc_is_busy(dev)) {
>
> Do you want to reset before waiting for TX action?
>
> I think it is safer t
Re: [PATCH] treewide: Remove stringification from __alias macro definition
On Thu, Oct 29, 2020 at 08:07:31PM -0700, Joe Perches wrote:
> Like the old __section macro, the __alias macro uses macro # stringification
> to create quotes around the symbol name used in the __attribute__.
>
> This can cause differences between gcc and clang when the stringification
> itself contains a quote character. So avoid these differences by always
> using quotes to define the aliased symbol.
>
> Remove the stringification and add quotes and when necessary a stringification
> when existing uses have a ## concatenation.
>
> Signed-off-by: Joe Perches
Reviewed-by: Nathan Chancellor
> ---
>
> Unlike the __section macro conversion in commit 33def8498fdd
> ("treewide: Convert macro and uses of __section(foo) to __section("foo")")
> this one was done by hand.
>
> No other use of __alias exists in the kernel.
>
> This patch does _not_ convert any uses of __attribute__((alias("")))
> so it should not cause any compilation issues.
>
> arch/x86/boot/compressed/string.c | 6 +++---
> arch/x86/include/asm/syscall_wrapper.h | 2 +-
> drivers/firmware/efi/runtime-wrappers.c | 2 +-
> include/linux/compiler_attributes.h | 2 +-
> kernel/kcsan/core.c | 10 +-
> lib/crc32.c | 4 ++--
> lib/crypto/aes.c| 4 ++--
> mm/kasan/generic.c | 8
> 8 files changed, 19 insertions(+), 19 deletions(-)
>
> diff --git a/arch/x86/boot/compressed/string.c
> b/arch/x86/boot/compressed/string.c
> index 81fc1eaa3229..d38b122f51ef 100644
> --- a/arch/x86/boot/compressed/string.c
> +++ b/arch/x86/boot/compressed/string.c
> @@ -75,7 +75,7 @@ void *memcpy(void *dest, const void *src, size_t n)
> }
>
> #ifdef CONFIG_KASAN
> -extern void *__memset(void *s, int c, size_t n) __alias(memset);
> -extern void *__memmove(void *dest, const void *src, size_t n)
> __alias(memmove);
> -extern void *__memcpy(void *dest, const void *src, size_t n) __alias(memcpy);
> +extern void *__memset(void *s, int c, size_t n) __alias("memset");
> +extern void *__memmove(void *dest, const void *src, size_t n)
> __alias("memmove");
> +extern void *__memcpy(void *dest, const void *src, size_t n)
> __alias("memcpy");
> #endif
> diff --git a/arch/x86/include/asm/syscall_wrapper.h
> b/arch/x86/include/asm/syscall_wrapper.h
> index a84333adeef2..f19d1bbbff3d 100644
> --- a/arch/x86/include/asm/syscall_wrapper.h
> +++ b/arch/x86/include/asm/syscall_wrapper.h
> @@ -69,7 +69,7 @@ extern long __ia32_sys_ni_syscall(const struct pt_regs
> *regs);
> long __##abi##_##name(const struct pt_regs *regs); \
> ALLOW_ERROR_INJECTION(__##abi##_##name, ERRNO); \
> long __##abi##_##name(const struct pt_regs *regs) \
> - __alias(__do_##name);
> + __alias("__do_" #name);
>
> #define __SYS_STUBx(abi, name, ...) \
> long __##abi##_##name(const struct pt_regs *regs); \
> diff --git a/drivers/firmware/efi/runtime-wrappers.c
> b/drivers/firmware/efi/runtime-wrappers.c
> index 1410beaef5c3..14e380ac65d4 100644
> --- a/drivers/firmware/efi/runtime-wrappers.c
> +++ b/drivers/firmware/efi/runtime-wrappers.c
> @@ -162,7 +162,7 @@ static DEFINE_SEMAPHORE(efi_runtime_lock);
> * Expose the EFI runtime lock to the UV platform
> */
> #ifdef CONFIG_X86_UV
> -extern struct semaphore __efi_uv_runtime_lock __alias(efi_runtime_lock);
> +extern struct semaphore __efi_uv_runtime_lock __alias("efi_runtime_lock");
> #endif
>
> /*
> diff --git a/include/linux/compiler_attributes.h
> b/include/linux/compiler_attributes.h
> index ea7b756b1c8f..4819512c9abd 100644
> --- a/include/linux/compiler_attributes.h
> +++ b/include/linux/compiler_attributes.h
> @@ -42,7 +42,7 @@
> /*
> * gcc:
> https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#index-alias-function-attribute
> */
> -#define __alias(symbol) __attribute__((__alias__(#symbol)))
> +#define __alias(symbol) __attribute__((__alias__(symbol)))
>
> /*
> * gcc:
> https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#index-aligned-function-attribute
> diff --git a/kernel/kcsan/core.c b/kernel/kcsan/core.c
> index 3994a217bde7..465f6cfc317c 100644
> --- a/kernel/kcsan/core.c
> +++ b/kernel/kcsan/core.c
> @@ -814,7 +814,7 @@ EXPORT_SYMBOL(__kcsan_check_access);
> } \
> EXPORT_SYMBOL(__tsan_read##size); \
> void __tsan_unaligned_read##size(void *ptr)\
> - __alias(__tsan_read##size);\
> + __alias("__tsan_read" #size); \
> EXPORT_SYMBOL(__tsan_unaligned_read##size);\
> void __tsan_write##size(void *ptr);
[PATCH v2 01/39] scripts: get_abi.pl: change script to allow parsing in ReST mode
Right now, several ABI files won't parse as ReST, as they
contain severe violations to the spec, with makes the script
to crash.
So, the code has a sanity logic with escapes bad code and
cleans tags that can cause Sphinx to crash.
Add support for disabling this mode.
Right now, as enabling rst-mode causes crash, it is disabled
by default.
Signed-off-by: Mauro Carvalho Chehab
---
scripts/get_abi.pl | 74 ++
1 file changed, 48 insertions(+), 26 deletions(-)
diff --git a/scripts/get_abi.pl b/scripts/get_abi.pl
index c738cb795514..107672cdacb3 100755
--- a/scripts/get_abi.pl
+++ b/scripts/get_abi.pl
@@ -12,8 +12,14 @@ my $man;
my $debug;
my $prefix="Documentation/ABI";
+#
+# If true, assumes that the description is formatted with ReST
+#
+my $description_is_rst = 0;
+
GetOptions(
"debug|d+" => \$debug,
+ "rst-source!" => \$description_is_rst,
"dir=s" => \$prefix,
'help|?' => \$help,
man => \$man
@@ -137,14 +143,15 @@ sub parse_abi {
next;
}
if ($tag eq "description") {
- next if ($content =~ m/^\s*$/);
- if ($content =~ m/^(\s*)(.*)/) {
- my $new_content = $2;
- $space = $new_tag . $sep . $1;
- while ($space =~ s/\t+/' ' x
(length($&) * 8 - length($`) % 8)/e) {}
- $space =~ s/./ /g;
- $data{$what}->{$tag} .=
"$new_content\n";
+ # Preserve initial spaces for the first
line
+ $content = ' ' x length($new_tag) .
$sep . $content;
+ $content =~ s,^(\s*):,$1 ,;
+ if ($content =~ m/^(\s*)(.*)$/) {
+ $space = $1;
+ $content = $2;
}
+ while ($space =~ s/\t+/' ' x
(length($&) * 8 - length($`) % 8)/e) {}
+ $data{$what}->{$tag} .= $content;
} else {
$data{$what}->{$tag} = $content;
}
@@ -160,11 +167,15 @@ sub parse_abi {
if ($tag eq "description") {
if (!$data{$what}->{description}) {
- next if (m/^\s*\n/);
+ s/^($space)//;
if (m/^(\s*)(.*)/) {
- $space = $1;
- while ($space =~ s/\t+/' ' x
(length($&) * 8 - length($`) % 8)/e) {}
- $data{$what}->{$tag} .= "$2\n";
+ my $sp = $1;
+ while ($sp =~ s/\t+/' ' x (length($&) *
8 - length($`) % 8)/e) {}
+ my $content = "$sp$2";
+
+ $content =~ s/^($space)//;
+
+ $data{$what}->{$tag} .= "$content";
}
} else {
my $content = $_;
@@ -274,23 +285,27 @@ sub output_rest {
print "Defined on file :ref:`$file <$fileref>`\n\n" if ($type
ne "File");
my $desc = $data{$what}->{description};
- $desc =~ s/^\s+//;
-
- # Remove title markups from the description, as they won't work
- $desc =~ s/\n[\-\*\=\^\~]+\n/\n/g;
if (!($desc =~ /^\s*$/)) {
- if ($desc =~ m/\:\n/ || $desc =~ m/\n[\t ]+/ || $desc
=~ m/[\x00-\x08\x0b-\x1f\x7b-\xff]/) {
- # put everything inside a code block
- $desc =~ s/\n/\n /g;
-
- print "::\n\n";
- print " $desc\n\n";
- } else {
- # Escape any special chars from description
- $desc
=~s/([\x00-\x08\x0b-\x1f\x21-\x2a\x2d\x2f\x3c-\x40\x5c\x5e-\x60\x7b-\xff])/\\$1/g;
-
+ if ($description_is_rst) {
print "$desc\n\n";
+ } else {
+ $desc =~ s/^\s+//;
+
+ # Remove title markups from the description, as
they won't work
+ $desc =~ s/\n[\-\*\=\^\~]+\n/\n\n/g;
+
+ if ($desc =~ m/\:\n/ || $desc =~ m/\n[\t ]+/
[PATCH v2 32/39] docs: ABI: change read/write attributes
Unfortunately, (R) and (W) are valid markups for enumerated lists, as described at: https://docutils.sourceforge.io/docs/ref/rst/restructuredtext.html#enumerated-lists So, we ned to replace them by: (R) -> (Read) (W) -> (Write) As otherwise, (R) will be displayed as R., with is not what it is desired. There's no need to touch (RO) and (RW). Signed-off-by: Mauro Carvalho Chehab --- Documentation/ABI/testing/debugfs-moxtet | 2 +- .../ABI/testing/debugfs-turris-mox-rwtm | 15 ++-- .../testing/sysfs-bus-coresight-devices-cti | 60 +++ .../testing/sysfs-bus-coresight-devices-etb10 | 16 ++-- .../testing/sysfs-bus-coresight-devices-etm3x | 10 +-- .../testing/sysfs-bus-coresight-devices-etm4x | 76 +-- .../testing/sysfs-bus-coresight-devices-stm | 2 +- .../testing/sysfs-bus-coresight-devices-tmc | 20 ++--- .../ABI/testing/sysfs-bus-moxtet-devices | 6 +- .../testing/sysfs-firmware-turris-mox-rwtm| 10 +-- 10 files changed, 109 insertions(+), 108 deletions(-) diff --git a/Documentation/ABI/testing/debugfs-moxtet b/Documentation/ABI/testing/debugfs-moxtet index 15dfaecb2892..6eee10c3d5a1 100644 --- a/Documentation/ABI/testing/debugfs-moxtet +++ b/Documentation/ABI/testing/debugfs-moxtet @@ -2,7 +2,7 @@ What: /sys/kernel/debug/moxtet/input Date: March 2019 KernelVersion: 5.3 Contact: Marek Behún -Description: (R) Read input from the shift registers, in hexadecimal. +Description: (Read) Read input from the shift registers, in hexadecimal. Returns N+1 bytes, where N is the number of Moxtet connected modules. The first byte is from the CPU board itself. diff --git a/Documentation/ABI/testing/debugfs-turris-mox-rwtm b/Documentation/ABI/testing/debugfs-turris-mox-rwtm index ad08f535af3b..326df1b74707 100644 --- a/Documentation/ABI/testing/debugfs-turris-mox-rwtm +++ b/Documentation/ABI/testing/debugfs-turris-mox-rwtm @@ -4,10 +4,11 @@ KernelVersion:5.8 Contact: Marek Behún Description: - === === - (W) Message to sign with the ECDSA private key stored in - device's OTP. The message must be exactly 64 bytes (since - this is intended for SHA-512 hashes). - (R) The resulting signature, 136 bytes. This contains the R and - S values of the ECDSA signature, both in big-endian format. - === === + === === + (Write) Message to sign with the ECDSA private key stored in + device's OTP. The message must be exactly 64 bytes + (since this is intended for SHA-512 hashes). + (Read) The resulting signature, 136 bytes. This contains the + R and S values of the ECDSA signature, both in + big-endian format. + === === diff --git a/Documentation/ABI/testing/sysfs-bus-coresight-devices-cti b/Documentation/ABI/testing/sysfs-bus-coresight-devices-cti index 9d11502b4390..bf2869c413e7 100644 --- a/Documentation/ABI/testing/sysfs-bus-coresight-devices-cti +++ b/Documentation/ABI/testing/sysfs-bus-coresight-devices-cti @@ -8,50 +8,50 @@ What: /sys/bus/coresight/devices//powered Date: March 2020 KernelVersion 5.7 Contact: Mike Leach or Mathieu Poirier -Description: (R) Indicate if the CTI hardware is powered. +Description: (Read) Indicate if the CTI hardware is powered. What: /sys/bus/coresight/devices//ctmid Date: March 2020 KernelVersion 5.7 Contact: Mike Leach or Mathieu Poirier -Description: (R) Display the associated CTM ID +Description: (Read) Display the associated CTM ID What: /sys/bus/coresight/devices//nr_trigger_cons Date: March 2020 KernelVersion 5.7 Contact: Mike Leach or Mathieu Poirier -Description: (R) Number of devices connected to triggers on this CTI +Description: (Read) Number of devices connected to triggers on this CTI What: /sys/bus/coresight/devices//triggers/name Date: March 2020 KernelVersion 5.7 Contact: Mike Leach or Mathieu Poirier -Description: (R) Name of connected device +Description: (Read) Name of connected device What: /sys/bus/coresight/devices//triggers/in_signals Date: March 2020 KernelVersion 5.7 Contact: Mike Leach or Mathieu Poirier -Description: (R) Input trigger signals from connected device +Description: (Read) Input trigger signals from connected device What: /sys/bus/coresight/devices//triggers/in_types Date: March 2020 KernelVersion 5.7 Contact:
[PATCH v2 12/39] docs: kernel_abi.py: add a script to parse ABI documentation
The ABI documentation is special: it is not plain text files,
but, instead, files with an strict format, as specified by
Documentation/ABI/README.
Add a parser for it.
Signed-off-by: Mauro Carvalho Chehab
---
Documentation/sphinx/kernel_abi.py | 157 +
1 file changed, 157 insertions(+)
create mode 100644 Documentation/sphinx/kernel_abi.py
diff --git a/Documentation/sphinx/kernel_abi.py
b/Documentation/sphinx/kernel_abi.py
new file mode 100644
index ..f8e7a02066c2
--- /dev/null
+++ b/Documentation/sphinx/kernel_abi.py
@@ -0,0 +1,157 @@
+# -*- coding: utf-8; mode: python -*-
+# SPDX-License-Identifier: GPL-2.0
+u"""
+kernel-abi
+~~
+
+Implementation of the ``kernel-abi`` reST-directive.
+
+:copyright: Copyright (C) 2016 Markus Heiser
+:copyright: Copyright (C) 2016-2020 Mauro Carvalho Chehab
+:maintained-by: Mauro Carvalho Chehab
+:license:GPL Version 2, June 1991 see Linux/COPYING for details.
+
+The ``kernel-abi`` (:py:class:`KernelCmd`) directive calls the
+scripts/get_abi.pl script to parse the Kernel ABI files.
+
+Overview of directive's argument and options.
+
+.. code-block:: rst
+
+.. kernel-abi::
+:debug:
+
+The argument is required. It contains the
+location of the ABI files to be parsed.
+
+``debug``
+ Inserts a code-block with the *raw* reST. Sometimes it is helpful to see
+ what reST is generated.
+
+"""
+
+import sys
+import os
+from os import path
+import subprocess
+
+from sphinx.ext.autodoc import AutodocReporter
+
+from docutils import nodes
+from docutils.parsers.rst import Directive, directives
+from docutils.statemachine import ViewList
+from docutils.utils.error_reporting import ErrorString
+
+
+__version__ = '1.0'
+
+# We can't assume that six is installed
+PY3 = sys.version_info[0] == 3
+PY2 = sys.version_info[0] == 2
+if PY3:
+# pylint: disable=C0103, W0622
+unicode = str
+basestring = str
+
+def setup(app):
+
+app.add_directive("kernel-abi", KernelCmd)
+return dict(
+version = __version__
+, parallel_read_safe = True
+, parallel_write_safe = True
+)
+
+class KernelCmd(Directive):
+
+u"""KernelABI (``kernel-abi``) directive"""
+
+required_arguments = 1
+optional_arguments = 0
+has_content = False
+final_argument_whitespace = True
+
+option_spec = {
+"debug" : directives.flag
+}
+
+def warn(self, message, **replace):
+replace["fname"] = self.state.document.current_source
+replace["line_no"] = replace.get("line_no", self.lineno)
+message = ("%(fname)s:%(line_no)s: [kernel-abi WARN] : " + message) %
replace
+self.state.document.settings.env.app.warn(message, prefix="")
+
+def run(self):
+
+doc = self.state.document
+if not doc.settings.file_insertion_enabled:
+raise self.warning("docutils: file insertion disabled")
+
+env = doc.settings.env
+cwd = path.dirname(doc.current_source)
+cmd = "get_abi.pl rest --dir "
+cmd += self.arguments[0]
+
+srctree = path.abspath(os.environ["srctree"])
+
+fname = cmd
+
+# extend PATH with $(srctree)/scripts
+path_env = os.pathsep.join([
+srctree + os.sep + "scripts",
+os.environ["PATH"]
+])
+shell_env = os.environ.copy()
+shell_env["PATH"]= path_env
+shell_env["srctree"] = srctree
+
+lines = self.runCmd(cmd, shell=True, cwd=cwd, env=shell_env)
+nodeList = self.nestedParse(lines, fname)
+return nodeList
+
+def runCmd(self, cmd, **kwargs):
+u"""Run command ``cmd`` and return it's stdout as unicode."""
+
+try:
+proc = subprocess.Popen(
+cmd
+, stdout = subprocess.PIPE
+, stderr = subprocess.PIPE
+, universal_newlines = True
+, **kwargs
+)
+out, err = proc.communicate()
+if err:
+self.warn(err)
+if proc.returncode != 0:
+raise self.severe(
+u"command '%s' failed with return code %d"
+% (cmd, proc.returncode)
+)
+except OSError as exc:
+raise self.severe(u"problems with '%s' directive: %s."
+ % (self.name, ErrorString(exc)))
+return unicode(out)
+
+def nestedParse(self, lines, fname):
+content = ViewList()
+node= nodes.section()
+
+if "debug" in self.options:
+code_block = "\n\n.. code-block:: rst\n:linenos:\n"
+for l in lines.split("\n"):
+code_block += "\n" + l
+lines = code_block + "\n\n"
+
+for c, l in enumerate(lines.split("\n")):
+content.append(l, fname, c)
+
+buf = self.sta
[PATCH v2 05/39] scripts: get_abi.pl: cleanup ABI cross-reference logic
Right now, the cross-references are generated on a single
step, when doing ReST output.
While this is nice optimization, it prevents auto-creating
cross-references for ABI symbols.
So, split it into a separate logic.
While here, turn on Perl warnings, as it helps to debug
problems inside the script.
Signed-off-by: Mauro Carvalho Chehab
---
scripts/get_abi.pl | 147 +
1 file changed, 83 insertions(+), 64 deletions(-)
diff --git a/scripts/get_abi.pl b/scripts/get_abi.pl
index bd018eb3815b..d134cc1692ee 100755
--- a/scripts/get_abi.pl
+++ b/scripts/get_abi.pl
@@ -2,15 +2,16 @@
# SPDX-License-Identifier: GPL-2.0
use strict;
+use warnings;
use Pod::Usage;
use Getopt::Long;
use File::Find;
use Fcntl ':mode';
-my $help;
-my $man;
-my $debug;
-my $enable_lineno;
+my $help = 0;
+my $man = 0;
+my $debug = 0;
+my $enable_lineno = 0;
my $prefix="Documentation/ABI";
#
@@ -40,6 +41,7 @@ pod2usage(2) if ($cmd eq "search" && !$arg);
require Data::Dumper if ($debug);
my %data;
+my %symbols;
#
# Displays an error message, printing file name and line
@@ -76,12 +78,12 @@ sub parse_abi {
my $what;
my $new_what;
- my $tag;
+ my $tag = "";
my $ln;
my $xrefs;
my $space;
my @labels;
- my $label;
+ my $label = "";
print STDERR "Opening $file\n" if ($debug > 1);
open IN, $file;
@@ -110,10 +112,18 @@ sub parse_abi {
if ($new_tag =~ m/what/) {
$space = "";
+ $content =~ s/[,.;]$//;
+
if ($tag =~ m/what/) {
$what .= ", " . $content;
} else {
- parse_error($file, $ln, "What '$what'
doesn't have a description", "") if ($what && !$data{$what}->{description});
+ if ($what) {
+ parse_error($file, $ln, "What
'$what' doesn't have a description", "") if (!$data{$what}->{description});
+
+ foreach my $w(split /, /,
$what) {
+ $symbols{$w} = $what;
+ };
+ }
$what = $content;
$label = $content;
@@ -122,7 +132,7 @@ sub parse_abi {
push @labels, [($content, $label)];
$tag = $new_tag;
- push @{$data{$nametag}->{xrefs}}, [($content,
$label)] if ($data{$nametag}->{what});
+ push @{$data{$nametag}->{symbols}}, $content if
($data{$nametag}->{what});
next;
}
@@ -132,7 +142,7 @@ sub parse_abi {
$data{$what}->{line_no} = $ln;
if ($new_what) {
- @{$data{$what}->{label}} = @labels if
($data{$nametag}->{what});
+ @{$data{$what}->{label_list}} = @labels
if ($data{$nametag}->{what});
@labels = ();
$label = "";
$new_what = 0;
@@ -203,36 +213,24 @@ sub parse_abi {
# Everything else is error
parse_error($file, $ln, "Unexpected line:", $_);
}
- $data{$nametag}->{description} =~ s/^\n+//;
+ $data{$nametag}->{description} =~ s/^\n+// if
($data{$nametag}->{description});
+ if ($what) {
+ parse_error($file, $ln, "What '$what' doesn't have a
description", "") if (!$data{$what}->{description});
+
+ foreach my $w(split /, /,$what) {
+ $symbols{$w} = $what;
+ };
+ }
close IN;
}
-#
-# Outputs the book on ReST format
-#
+sub create_labels {
+ my %labels;
-my %labels;
+ foreach my $what (keys %data) {
+ next if ($data{$what}->{file} eq "File");
-sub output_rest {
- foreach my $what (sort {
- ($data{$a}->{type} eq "File") cmp
($data{$b}->{type} eq "File") ||
- $a cmp $b
- } keys %data) {
- my $type = $data{$what}->{type};
- my $file = $data{$what}->{file};
- my $filepath = $data{$what}->{filepath};
-
- if ($enable_lineno) {
- printf "#define LINENO %s%s#%s\n\n",
- $prefix, $data{$what}->{file},
- $data{$what}->{line_no};
- }
-
- my $w = $what;
- $w =~ s/([\(\)\_\-\*
[PATCH v2 28/39] docs: ABI: fix syntax to be parsed using ReST notation
There are a number of new changes at the ABI files that cause
them to produce warnings when generating ABI output.
Fix them.
Signed-off-by: Mauro Carvalho Chehab
---
.../ABI/stable/sysfs-driver-firmware-zynqmp | 62 -
Documentation/ABI/testing/debugfs-moxtet | 28 --
.../ABI/testing/debugfs-turris-mox-rwtm | 6 +-
.../sysfs-bus-event_source-devices-dfl_fme| 14 +--
Documentation/ABI/testing/sysfs-bus-most | 6 +-
Documentation/ABI/testing/sysfs-class-devfreq | 6 +-
Documentation/ABI/testing/sysfs-class-ocxl| 14 +--
.../ABI/testing/sysfs-class-power-wilco | 18 ++--
.../ABI/testing/sysfs-class-rnbd-client | 93 ++-
.../ABI/testing/sysfs-class-rtrs-client | 23 +++--
.../sysfs-devices-platform-stratix10-rsu | 10 ++
.../ABI/testing/sysfs-driver-w1_therm | 75 ++-
.../ABI/testing/sysfs-platform-dfl-fme| 14 ++-
Documentation/ABI/testing/sysfs-platform-dptf | 11 ++-
.../sysfs-platform-intel-wmi-sbl-fw-update| 1 +
.../testing/sysfs-platform-mellanox-bootctl | 50 ++
.../ABI/testing/sysfs-platform-wilco-ec | 1 +
17 files changed, 271 insertions(+), 161 deletions(-)
diff --git a/Documentation/ABI/stable/sysfs-driver-firmware-zynqmp
b/Documentation/ABI/stable/sysfs-driver-firmware-zynqmp
index 00fa04c76ff3..f5724bb5b462 100644
--- a/Documentation/ABI/stable/sysfs-driver-firmware-zynqmp
+++ b/Documentation/ABI/stable/sysfs-driver-firmware-zynqmp
@@ -12,13 +12,15 @@ Description:
resets. Three registers are used by the FSBL and
other Xilinx software products: GLOBAL_GEN_STORAGE{4:6}.
- Usage:
- # cat /sys/devices/platform/firmware\:zynqmp-firmware/ggs0
- # echo >
/sys/devices/platform/firmware\:zynqmp-firmware/ggs0
+ Usage::
- Example:
- # cat /sys/devices/platform/firmware\:zynqmp-firmware/ggs0
- # echo 0x1234ABCD >
/sys/devices/platform/firmware\:zynqmp-firmware/ggs0
+ # cat /sys/devices/platform/firmware\:zynqmp-firmware/ggs0
+ # echo >
/sys/devices/platform/firmware\:zynqmp-firmware/ggs0
+
+ Example::
+
+ # cat /sys/devices/platform/firmware\:zynqmp-firmware/ggs0
+ # echo 0x1234ABCD >
/sys/devices/platform/firmware\:zynqmp-firmware/ggs0
Users: Xilinx
@@ -39,13 +41,15 @@ Description:
software products: PERS_GLOB_GEN_STORAGE{4:7}.
Register is reset only by a POR reset.
- Usage:
- # cat /sys/devices/platform/firmware\:zynqmp-firmware/pggs0
- # echo >
/sys/devices/platform/firmware\:zynqmp-firmware/pggs0
+ Usage::
- Example:
- # cat /sys/devices/platform/firmware\:zynqmp-firmware/pggs0
- # echo 0x1234ABCD >
/sys/devices/platform/firmware\:zynqmp-firmware/pggs0
+ # cat /sys/devices/platform/firmware\:zynqmp-firmware/pggs0
+ # echo >
/sys/devices/platform/firmware\:zynqmp-firmware/pggs0
+
+ Example::
+
+ # cat /sys/devices/platform/firmware\:zynqmp-firmware/pggs0
+ # echo 0x1234ABCD >
/sys/devices/platform/firmware\:zynqmp-firmware/pggs0
Users: Xilinx
@@ -61,23 +65,28 @@ Description:
Following are available shutdown scopes(subtypes):
- subsystem: Only the APU along with all of its peripherals
+ subsystem:
+ Only the APU along with all of its peripherals
not used by other processing units will be
shut down. This may result in the FPD power
domain being shut down provided that no other
processing unit uses FPD peripherals or DRAM.
- ps_only:The complete PS will be shut down, including the
+ ps_only:
+ The complete PS will be shut down, including the
RPU, PMU, etc. Only the PL domain (FPGA)
remains untouched.
- system: The complete system/device is shut down.
+ system:
+ The complete system/device is shut down.
- Usage:
- # cat
/sys/devices/platform/firmware\:zynqmp-firmware/shutdown_scope
- # echo >
/sys/devices/platform/firmware\:zynqmp-firmware/shutdown_scope
+ Usage::
- Example:
- # cat
/sys/devices/platform/firmware\:zynqmp-firmware/shutdown_scope
- # echo "subsystem" >
/sys/devices/platform/firmware\:zynqmp-firmware/shutdown_scope
+ # cat
/sys/devices/platform/firmware\:zynqmp-firm
[PATCH v2 11/39] docs: kernellog.py: add support for info()
An extension may want to just inform about something. So, add support for it. Signed-off-by: Mauro Carvalho Chehab --- Documentation/sphinx/kernellog.py | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/Documentation/sphinx/kernellog.py b/Documentation/sphinx/kernellog.py index af924f51a7dc..8ac7d274f542 100644 --- a/Documentation/sphinx/kernellog.py +++ b/Documentation/sphinx/kernellog.py @@ -25,4 +25,8 @@ def verbose(app, message): else: app.verbose(message) - +def info(app, message): +if UseLogging: +logger.info(message) +else: +app.info(message) -- 2.26.2
[PATCH v2 00/39] ABI: add it to the documentation build system
Hi Greg, That's the second version of the ABI documentation patches, adding support for having the Linux ABI documentted inside the Linux admin manual. When compared with the version I sent years ago, this version has: - a logic to detect duplicated ABI symbols; - it auto-generate cross-reference markups for ABI symbols, ABI files and .rst files; - Other files from 5.10-rc1 required adjustments in order to be accepted by the script in rst-source mode; - Some bug fixes. v2: - fixed pedantic warnings with "search command; - fixed the duplicated warning output in order to report properly the files; - added a few more patches addressing ABI duplication. Mauro Carvalho Chehab (39): scripts: get_abi.pl: change script to allow parsing in ReST mode scripts: get_abi.pl: fix parsing on ReST mode scripts: get_abi.pl: Allow optionally record from where a line came from scripts: get_abi.pl: improve its parser to better catch up indentation scripts: get_abi.pl: cleanup ABI cross-reference logic scripts: get_abi.pl: detect duplicated ABI definitions scripts: get_abi.pl: output users in ReST format scripts: get_abi.pl: prevent duplicated file names scripts: get_abi.pl: use bold font for ABI definitions scripts: get_abi.pl: auto-generate cross references docs: kernellog.py: add support for info() docs: kernel_abi.py: add a script to parse ABI documentation docs: kernel_abi.py: fix UTF-8 support docs: kernel_abi.py: make it compatible with Sphinx 1.7+ docs: kernel_abi.py: use --enable-lineno for get_abi.pl docs: kernel_abi.py: Handle with a lazy Sphinx parser docs: add ABI documentation to the admin-guide book docs: ABI: README: specify that files should be ReST compatible docs: ABI: stable: make files ReST compatible docs: ABI: testing: make the files compatible with ReST output docs: ABI: sysfs-uevent: make it compatible with ReST output docs: ABI: make it parse ABI/stable as ReST-compatible files docs: ABI: create a 2-depth index for ABI docs: ABI: don't escape ReST-incompatible chars from obsolete and removed docs: abi-testing.rst: enable --rst-sources when building docs docs: Kconfig/Makefile: add a check for broken ABI files docs: ABI: convert testing/configfs-acpi to ReST docs: ABI: fix syntax to be parsed using ReST notation docs: ABI: vdso: use the right format for ABI docs: ABI: sysfs-bus-nvdimm: use the right format for ABI docs: ABI: cleanup several ABI documents docs: ABI: change read/write attributes docs: ABI: stable: remove a duplicated documentation docs: ABI: unify /sys/class/leds//brightness documentation docs: ABI: sysfs-class-power: unify duplicated properties docs: ABI: sysfs-c2port: remove a duplicated entry docs: ABI: sysfs-class-backlight: unify ABI documentation docs: ABI: sysfs-class-led-trigger-pattern: remove hw_pattern duplication scripts: get_abi.pl: assume ReST format by default Documentation/ABI/README | 10 +- Documentation/ABI/obsolete/sysfs-class-dax| 8 +- .../ABI/obsolete/sysfs-driver-hid-roccat-pyra | 3 + Documentation/ABI/obsolete/sysfs-gpio | 2 + Documentation/ABI/removed/devfs | 1 + Documentation/ABI/removed/raw1394 | 1 + Documentation/ABI/removed/sysfs-class-rfkill | 2 +- Documentation/ABI/removed/video1394 | 1 + Documentation/ABI/stable/firewire-cdev| 67 ++- Documentation/ABI/stable/sysfs-acpi-pmprofile | 26 +- Documentation/ABI/stable/sysfs-bus-firewire | 3 + Documentation/ABI/stable/sysfs-bus-nvmem | 19 +- Documentation/ABI/stable/sysfs-bus-usb| 6 +- Documentation/ABI/stable/sysfs-bus-vmbus | 7 - Documentation/ABI/stable/sysfs-bus-w1 | 1 + .../ABI/stable/sysfs-class-backlight | 1 + .../ABI/stable/sysfs-class-infiniband | 93 +++- Documentation/ABI/stable/sysfs-class-rfkill | 13 +- Documentation/ABI/stable/sysfs-class-tpm | 94 ++-- Documentation/ABI/stable/sysfs-devices| 5 +- .../ABI/stable/sysfs-driver-firmware-zynqmp | 62 ++- Documentation/ABI/stable/sysfs-driver-ib_srp | 1 + Documentation/ABI/stable/sysfs-driver-speakup | 4 + .../ABI/stable/sysfs-firmware-efi-vars| 4 + .../ABI/stable/sysfs-firmware-opal-dump | 5 + .../ABI/stable/sysfs-firmware-opal-elog | 2 + Documentation/ABI/stable/sysfs-hypervisor-xen | 3 + Documentation/ABI/stable/vdso | 11 +- Documentation/ABI/testing/configfs-acpi | 34 +- Documentation/ABI/testing/configfs-most | 135 +++-- .../ABI/testing/configfs-spear-pcie-gadget| 36 +- Documentation/ABI/testing/configfs-usb-gadget | 83 +-- .../ABI/testing/configfs-usb-gadget-ecm | 12 +- .../ABI/testing/configfs-usb-gadget-eem | 10 +- .../ABI/testing/configfs-usb-gadget-hid | 10 +- .../ABI/testing/configfs-usb-gadget-loopback | 6 +- .../testing/configfs-usb-gadget-mass-storag
[PATCH v2 19/39] docs: ABI: stable: make files ReST compatible
Several entries at the stable ABI files won't parse if we pass them directly to the ReST output. Adjust them, in order to allow adding their contents as-is at the stable ABI book. Signed-off-by: Mauro Carvalho Chehab --- Documentation/ABI/stable/firewire-cdev| 4 + Documentation/ABI/stable/sysfs-acpi-pmprofile | 22 +++-- Documentation/ABI/stable/sysfs-bus-firewire | 3 + Documentation/ABI/stable/sysfs-bus-nvmem | 19 ++-- Documentation/ABI/stable/sysfs-bus-usb| 6 +- .../ABI/stable/sysfs-class-backlight | 1 + .../ABI/stable/sysfs-class-infiniband | 93 +-- Documentation/ABI/stable/sysfs-class-rfkill | 13 ++- Documentation/ABI/stable/sysfs-class-tpm | 90 +- Documentation/ABI/stable/sysfs-devices| 5 +- Documentation/ABI/stable/sysfs-driver-ib_srp | 1 + .../ABI/stable/sysfs-firmware-efi-vars| 4 + .../ABI/stable/sysfs-firmware-opal-dump | 5 + .../ABI/stable/sysfs-firmware-opal-elog | 2 + Documentation/ABI/stable/sysfs-hypervisor-xen | 3 + Documentation/ABI/stable/vdso | 5 +- 16 files changed, 176 insertions(+), 100 deletions(-) diff --git a/Documentation/ABI/stable/firewire-cdev b/Documentation/ABI/stable/firewire-cdev index f72ed653878a..c9e8ff026154 100644 --- a/Documentation/ABI/stable/firewire-cdev +++ b/Documentation/ABI/stable/firewire-cdev @@ -14,12 +14,14 @@ Description: Each /dev/fw* is associated with one IEEE 1394 node, which can be remote or local nodes. Operations on a /dev/fw* file have different scope: + - The 1394 node which is associated with the file: - Asynchronous request transmission - Get the Configuration ROM - Query node ID - Query maximum speed of the path between this node and local node + - The 1394 bus (i.e. "card") to which the node is attached to: - Isochronous stream transmission and reception - Asynchronous stream transmission and reception @@ -31,6 +33,7 @@ Description: manager - Query cycle time - Bus reset initiation, bus reset event reception + - All 1394 buses: - Allocation of IEEE 1212 address ranges on the local link layers, reception of inbound requests to such @@ -43,6 +46,7 @@ Description: userland implement different access permission models, some operations are restricted to /dev/fw* files that are associated with a local node: + - Addition of descriptors or directories to the local nodes' Configuration ROM - PHY packet transmission and reception diff --git a/Documentation/ABI/stable/sysfs-acpi-pmprofile b/Documentation/ABI/stable/sysfs-acpi-pmprofile index 964c7a8afb26..fd97d22b677f 100644 --- a/Documentation/ABI/stable/sysfs-acpi-pmprofile +++ b/Documentation/ABI/stable/sysfs-acpi-pmprofile @@ -6,17 +6,21 @@ Description: The ACPI pm_profile sysfs interface exports the platform power management (and performance) requirement expectations as provided by BIOS. The integer value is directly passed as retrieved from the FADT ACPI table. -Values: For possible values see ACPI specification: + +Values:For possible values see ACPI specification: 5.2.9 Fixed ACPI Description Table (FADT) Field: Preferred_PM_Profile Currently these values are defined by spec: - 0 Unspecified - 1 Desktop - 2 Mobile - 3 Workstation - 4 Enterprise Server - 5 SOHO Server - 6 Appliance PC - 7 Performance Server + + == = + 0 Unspecified + 1 Desktop + 2 Mobile + 3 Workstation + 4 Enterprise Server + 5 SOHO Server + 6 Appliance PC + 7 Performance Server >7 Reserved + == = diff --git a/Documentation/ABI/stable/sysfs-bus-firewire b/Documentation/ABI/stable/sysfs-bus-firewire index 41e5a0cd1e3e..9ac9eddb82ef 100644 --- a/Documentation/ABI/stable/sysfs-bus-firewire +++ b/Documentation/ABI/stable/sysfs-bus-firewire @@ -47,6 +47,7 @@ Description: IEEE 1394 node device attribute. Read-only and immutable. Values:1: The sysfs entry represents a local node (a controller card). + 0: The sysfs entry represents a remote node. @@ -12
[PATCH v2 09/39] scripts: get_abi.pl: use bold font for ABI definitions
As we're using tables, let's distinguish the ones used by ABI
by using a bold font.
Signed-off-by: Mauro Carvalho Chehab
---
scripts/get_abi.pl | 1 +
1 file changed, 1 insertion(+)
diff --git a/scripts/get_abi.pl b/scripts/get_abi.pl
index 5612f019fae0..12a23f9a2f86 100755
--- a/scripts/get_abi.pl
+++ b/scripts/get_abi.pl
@@ -300,6 +300,7 @@ sub output_rest {
my $len = 0;
foreach my $name (@names) {
+ $name = "**$name**";
$len = length($name) if (length($name) > $len);
}
--
2.26.2
[PATCH v2 35/39] docs: ABI: sysfs-class-power: unify duplicated properties
The ABI is not supposed to have duplicated entries, as warned by get_abi.pl: $ ./scripts/get_abi.pl validate 2>&1|grep sysfs-class-power Warning: /sys/class/power_supply//current_avg is defined 2 times: Documentation/ABI/testing/sysfs-class-power:108 Documentation/ABI/testing/sysfs-class-power:391 Warning: /sys/class/power_supply//current_max is defined 2 times: Documentation/ABI/testing/sysfs-class-power:121 Documentation/ABI/testing/sysfs-class-power:404 Warning: /sys/class/power_supply//current_now is defined 2 times: Documentation/ABI/testing/sysfs-class-power:130 Documentation/ABI/testing/sysfs-class-power:414 Warning: /sys/class/power_supply//temp is defined 2 times: Documentation/ABI/testing/sysfs-class-power:281 Documentation/ABI/testing/sysfs-class-power:493 Warning: /sys/class/power_supply//temp_alert_max is defined 2 times: Documentation/ABI/testing/sysfs-class-power:291 Documentation/ABI/testing/sysfs-class-power:505 Warning: /sys/class/power_supply//temp_alert_min is defined 2 times: Documentation/ABI/testing/sysfs-class-power:306 Documentation/ABI/testing/sysfs-class-power:521 Warning: /sys/class/power_supply//temp_max is defined 2 times: Documentation/ABI/testing/sysfs-class-power:322 Documentation/ABI/testing/sysfs-class-power:537 Warning: /sys/class/power_supply//temp_min is defined 2 times: Documentation/ABI/testing/sysfs-class-power:333 Documentation/ABI/testing/sysfs-class-power:547 Warning: /sys/class/power_supply//voltage_max is defined 2 times: Documentation/ABI/testing/sysfs-class-power:356 Documentation/ABI/testing/sysfs-class-power:571 Warning: /sys/class/power_supply//voltage_min is defined 2 times: Documentation/ABI/testing/sysfs-class-power:367 Documentation/ABI/testing/sysfs-class-power:581 Warning: /sys/class/power_supply//voltage_now is defined 2 times: Documentation/ABI/testing/sysfs-class-power:378 Documentation/ABI/testing/sysfs-class-power:591 Yet, both USB and Battery share a common set of charging-related properties. Unify the entries for such properties in order to avoid duplication, while preserving the battery and USB-specific data properly documented. Signed-off-by: Mauro Carvalho Chehab --- Documentation/ABI/testing/sysfs-class-power | 486 +--- 1 file changed, 223 insertions(+), 263 deletions(-) diff --git a/Documentation/ABI/testing/sysfs-class-power b/Documentation/ABI/testing/sysfs-class-power index d68ad528a8e5..ca830c6cd809 100644 --- a/Documentation/ABI/testing/sysfs-class-power +++ b/Documentation/ABI/testing/sysfs-class-power @@ -36,7 +36,229 @@ Description: Access: Read Valid values: "Battery", "UPS", "Mains", "USB", "Wireless" -= Battery Properties = +**Battery and USB properties** + +What: /sys/class/power_supply//current_avg +Date: May 2007 +Contact: linux...@vger.kernel.org +Description: + Battery: + + Reports an average IBAT current reading for the battery, over + a fixed period. Normally devices will provide a fixed interval + in which they average readings to smooth out the reported + value. + + USB: + + Reports an average IBUS current reading over a fixed period. + Normally devices will provide a fixed interval in which they + average readings to smooth out the reported value. + + Access: Read + + Valid values: Represented in microamps. Negative values are + used for discharging batteries, positive values for charging + batteries and for USB IBUS current. + +What: /sys/class/power_supply//current_max +Date: October 2010 +Contact: linux...@vger.kernel.org +Description: + Battery: + + Reports the maximum IBAT current allowed into the battery. + + USB: + + Reports the maximum IBUS current the supply can support. + + Access: Read + Valid values: Represented in microamps + +What: /sys/class/power_supply//current_now +Date: May 2007 +Contact: linux...@vger.kernel.org +Description: + + Battery: + + Reports an instant, single IBAT current reading for the + battery. This value is not averaged/smoothed. + + Access: Read + + USB: + + Reports the IBUS current supplied now. This value is generally + read-only reporting, unless the 'online' state of the supply + is set to be programmable, in which case this value can be set + within the reported min/max range. + + Access: Read, Write + + Valid values: Represented in microamps. Negative values
[PATCH v2 34/39] docs: ABI: unify /sys/class/leds//brightness documentation
This ABI is defined twice, one for normal leds and another one for multicolor ones. Ensure that just one definition is there at ABI. Acked-by: Pavel Machek Signed-off-by: Mauro Carvalho Chehab --- Documentation/ABI/testing/sysfs-class-led | 25 --- .../ABI/testing/sysfs-class-led-multicolor| 23 + 2 files changed, 28 insertions(+), 20 deletions(-) diff --git a/Documentation/ABI/testing/sysfs-class-led b/Documentation/ABI/testing/sysfs-class-led index 0ed5c2629c6f..2e24ac3bd7ef 100644 --- a/Documentation/ABI/testing/sysfs-class-led +++ b/Documentation/ABI/testing/sysfs-class-led @@ -3,9 +3,26 @@ Date: March 2006 KernelVersion: 2.6.17 Contact: Richard Purdie Description: - Set the brightness of the LED. Most LEDs don't - have hardware brightness support, so will just be turned on for - non-zero brightness settings. The value is between 0 and + Set the brightness of the LED. + + Most LEDs don't have hardware brightness support, so will + just be turned on for non-zero brightness settings. + + .. Note:: + + For multicolor LEDs, writing to this file will update all + LEDs within the group to a calculated percentage of what + each color LED intensity is set to. + + The percentage is calculated for each grouped LED via + the equation below:: + + led_brightness = brightness * multi_intensity/max_brightness + + For additional details please refer to + Documentation/leds/leds-class-multicolor.rst. + + The value is between 0 and /sys/class/leds//max_brightness. Writing 0 to this file clears active trigger. @@ -13,6 +30,8 @@ Description: Writing non-zero to this file while trigger is active changes the top brightness trigger is going to use. + + What: /sys/class/leds//max_brightness Date: March 2006 KernelVersion: 2.6.17 diff --git a/Documentation/ABI/testing/sysfs-class-led-multicolor b/Documentation/ABI/testing/sysfs-class-led-multicolor index eeeddcbdbbe3..16fc827b10cb 100644 --- a/Documentation/ABI/testing/sysfs-class-led-multicolor +++ b/Documentation/ABI/testing/sysfs-class-led-multicolor @@ -1,20 +1,3 @@ -What: /sys/class/leds//brightness -Date: March 2020 -KernelVersion: 5.9 -Contact: Dan Murphy -Description: read/write - Writing to this file will update all LEDs within the group to a - calculated percentage of what each color LED intensity is set - to. The percentage is calculated for each grouped LED via the - equation below: - - led_brightness = brightness * multi_intensity/max_brightness - - For additional details please refer to - Documentation/leds/leds-class-multicolor.rst. - - The value of the LED is from 0 to - /sys/class/leds//max_brightness. What: /sys/class/leds//multi_index Date: March 2020 @@ -25,6 +8,9 @@ Description: read as an array of strings as they are indexed in the multi_intensity file. + For additional details please refer to + Documentation/leds/leds-class-multicolor.rst. + What: /sys/class/leds//multi_intensity Date: March 2020 KernelVersion: 5.9 @@ -33,3 +19,6 @@ Description: read/write This file contains array of integers. Order of components is described by the multi_index array. The maximum intensity should not exceed /sys/class/leds//max_brightness. + + For additional details please refer to + Documentation/leds/leds-class-multicolor.rst. -- 2.26.2
[PATCH v2 06/39] scripts: get_abi.pl: detect duplicated ABI definitions
The ABI should define only once each What. The current script
logic assumes that.
However, that's not the case, currently: there are several
symbols with a generic definition, and per-driver ones.
Better handle such cases, by preserving the cross-references
with the files that define them, but also track such
cases, producing warnings, as they should be fixed.
Signed-off-by: Mauro Carvalho Chehab
---
scripts/get_abi.pl | 85 +++---
1 file changed, 58 insertions(+), 27 deletions(-)
diff --git a/scripts/get_abi.pl b/scripts/get_abi.pl
index d134cc1692ee..1d1408fad130 100755
--- a/scripts/get_abi.pl
+++ b/scripts/get_abi.pl
@@ -114,6 +114,8 @@ sub parse_abi {
$space = "";
$content =~ s/[,.;]$//;
+ push @{$symbols{$content}->{file}}, " $file:" .
($ln - 1);
+
if ($tag =~ m/what/) {
$what .= ", " . $content;
} else {
@@ -121,7 +123,7 @@ sub parse_abi {
parse_error($file, $ln, "What
'$what' doesn't have a description", "") if (!$data{$what}->{description});
foreach my $w(split /, /,
$what) {
- $symbols{$w} = $what;
+ $symbols{$w}->{xref} =
$what;
};
}
@@ -139,8 +141,6 @@ sub parse_abi {
if ($tag ne "" && $new_tag) {
$tag = $new_tag;
- $data{$what}->{line_no} = $ln;
-
if ($new_what) {
@{$data{$what}->{label_list}} = @labels
if ($data{$nametag}->{what});
@labels = ();
@@ -148,9 +148,19 @@ sub parse_abi {
$new_what = 0;
$data{$what}->{type} = $type;
- $data{$what}->{file} = $name;
- $data{$what}->{filepath} = $file;
+ if (!defined($data{$what}->{file})) {
+ $data{$what}->{file} = $name;
+ $data{$what}->{filepath} =
$file;
+ } else {
+ if ($name ne
$data{$what}->{file}) {
+ $data{$what}->{file} .=
" " . $name;
+
$data{$what}->{filepath} .= " " . $file;
+ }
+ }
print STDERR "\twhat: $what\n" if
($debug > 1);
+ $data{$what}->{line_no} = $ln;
+ } else {
+ $data{$what}->{line_no} = $ln if
(!defined($data{$what}->{line_no}));
}
if (!$what) {
@@ -218,7 +228,7 @@ sub parse_abi {
parse_error($file, $ln, "What '$what' doesn't have a
description", "") if (!$data{$what}->{description});
foreach my $w(split /, /,$what) {
- $symbols{$w} = $what;
+ $symbols{$w}->{xref} = $what;
};
}
close IN;
@@ -267,29 +277,20 @@ sub output_rest {
$a cmp $b
} keys %data) {
my $type = $data{$what}->{type};
- my $file = $data{$what}->{file};
- my $filepath = $data{$what}->{filepath};
+
+ my @file = split / /, $data{$what}->{file};
+ my @filepath = split / /, $data{$what}->{filepath};
if ($enable_lineno) {
printf "#define LINENO %s%s#%s\n\n",
- $prefix, $data{$what}->{file},
+ $prefix, $file[0],
$data{$what}->{line_no};
}
my $w = $what;
$w =~ s/([\(\)\_\-\*\=\^\~\\])/\\$1/g;
- $filepath =~ s,.*/(.*/.*),$1,;;
- $filepath =~ s,[/\-],_,g;;
- my $fileref = "abi_file_".$filepath;
-
- if ($type eq "File") {
- my $bar = $w;
- $bar =~ s/./-/g;
-
- print ".. _$fileref:\n\n";
- print "$w\n$bar\n\n";
- } else {
+ if ($type ne "File") {
printf ".. _
[PATCH v2 38/39] docs: ABI: sysfs-class-led-trigger-pattern: remove hw_pattern duplication
The ABI files are supposed to be unique. Yet, in the specific case of hw_pattern, there are some duplicated entries as warned by scripts/get_abi.pl: Warning: /sys/class/leds//hw_pattern is defined 3 times: Documentation/ABI/testing/sysfs-class-led-trigger-pattern:14 Documentation/ABI/testing/sysfs-class-led-driver-sc27xx:0 Documentation/ABI/testing/sysfs-class-led-driver-el15203000:0 Drop the duplication from the ABI files, moving the specific definitions to files inside Documentation/leds. Signed-off-by: Mauro Carvalho Chehab --- .../testing/sysfs-class-led-driver-el15203000 | 135 - .../ABI/testing/sysfs-class-led-driver-sc27xx | 22 --- .../testing/sysfs-class-led-trigger-pattern | 4 +- Documentation/leds/index.rst | 1 + Documentation/leds/leds-el15203000.rst| 140 ++ Documentation/leds/leds-sc27xx.rst| 27 6 files changed, 170 insertions(+), 159 deletions(-) delete mode 100644 Documentation/ABI/testing/sysfs-class-led-driver-sc27xx create mode 100644 Documentation/leds/leds-el15203000.rst create mode 100644 Documentation/leds/leds-sc27xx.rst diff --git a/Documentation/ABI/testing/sysfs-class-led-driver-el15203000 b/Documentation/ABI/testing/sysfs-class-led-driver-el15203000 index da546e86deb5..04f3ffdc5936 100644 --- a/Documentation/ABI/testing/sysfs-class-led-driver-el15203000 +++ b/Documentation/ABI/testing/sysfs-class-led-driver-el15203000 @@ -1,138 +1,3 @@ -What: /sys/class/leds//hw_pattern -Date: September 2019 -KernelVersion: 5.5 -Description: - Specify a hardware pattern for the EL15203000 LED. - The LEDs board supports only predefined patterns by firmware - for specific LEDs. - - Breathing mode for Screen frame light tube:: - - "0 4000 1 4000" - - ^ - | - Max-| --- - |/ \ - | / \ - | / \ / - | / \ / - Min-|- --- - | - 0--4--8--> time (sec) - - Cascade mode for Pipe LED:: - - "1 800 2 800 4 800 8 800 16 800" - - ^ - | - 0 On -|+ ++ +--- - || || | - Off-|+---++---+ - | - 1 On -|++ ++ - ||| || - Off |++---++-- - | - 2 On -| ++ ++ - | || || - Off-|-++---++- - | - 3 On -| ++ ++ - | || || - Off-|--++---++ - | - 4 On -| ++ ++ - | || || - Off-|---++---++--- - | - 0---0.8--1.6--2.4--3.2---4---4.8--5.6--6.4--7.2---8--> time (sec) - - Inverted cascade mode for Pipe LED:: - - "30 800 29 800 27 800 23 800 15 800" - - ^ - | - 0 On -|+---++---+ - || || | - Off-|+ ++ +--- - | - 1 On -|++---++-- - ||| || - Off |++ ++ - | - 2 On -|-++---++- - | || || - Off-| ++ ++ - | - 3 On -|--++---++ - | || || - Off-| ++ ++ - | - 4 On -|---++---++--- - | ||
[PATCH v2 37/39] docs: ABI: sysfs-class-backlight: unify ABI documentation
Both adp8860 and adp8870 define some extensions to the backlight class. This causes warnings: Warning: /sys/class/backlight//ambient_light_level is defined 2 times: /sys/class/backlight//ambient_light_level:8 /sys/class/backlight//ambient_light_level:30 Warning: /sys/class/backlight//ambient_light_zone is defined 2 times: /sys/class/backlight//ambient_light_zone:18 /sys/class/backlight//ambient_light_zone:40 As ABI definitions shouldn't be duplicated. Unfortunately, the ABI is dependent on the specific device features. As such, ambient_light_level range is somewhat different among the supported devices. The ambient_light_zone is even worse: the meanings of each preset are different, and there's no ABI to retrieve the supported types nor their meanins. Unfortunately, it is too late to fix it without causing regressions, as this has been used since Kernel v2.6.35. Rewrite those ABI documentation using the current documentation as a reference, and double-checking at the datasheets: https://www.analog.com/media/en/technical-documentation/data-sheets/ADP8870.pdf https://www.analog.com/media/en/technical-documentation/data-sheets/ADP8860.pdf in order to properly document the differences between those two drivers. Signed-off-by: Mauro Carvalho Chehab --- .../ABI/testing/sysfs-class-backlight | 60 +++ .../ABI/testing/sysfs-class-backlight-adp8860 | 21 +-- .../sysfs-class-backlight-driver-adp8870 | 30 +- 3 files changed, 65 insertions(+), 46 deletions(-) diff --git a/Documentation/ABI/testing/sysfs-class-backlight b/Documentation/ABI/testing/sysfs-class-backlight index 3ab175a3f5cb..1fc86401bf95 100644 --- a/Documentation/ABI/testing/sysfs-class-backlight +++ b/Documentation/ABI/testing/sysfs-class-backlight @@ -24,3 +24,63 @@ Description: non-linear The brightness changes non-linearly with each step. Brightness controls should use a linear mapping for a linear perception. + +What: /sys/class/backlight//ambient_light_level +Date: Apr, 2010 +KernelVersion: v2.6.35 +Contact: Michael Hennerich +Description: + (RO) Get conversion value of the light sensor. + + The value is automatically updated every 80 ms when the + light sensor is enabled. + + The value range is device-driver specific: + + For ADP8870: + + It returns integer between 0 (dark) and 8000 (max ambient + brightness). + + For ADP8860: + + It returns a 13-bits integer. + +What: /sys/class/backlight//ambient_light_zone +Date: Apr, 2010 +KernelVersion: v2.6.35 +Contact: Michael Hennerich , + device-drivers-de...@blackfin.uclinux.org + +Description: + (RW) Read or write the specific brightness level at which the + backlight operates. + + The value meaning is device-driver specific: + + For ADP8860: + + ==== + 0Off: Backlight set to 0 mA + 1Level 1: daylight + 2Level 2: bright + 3Level 3: dark + ==== + + For ADP8870: + + ==== + 0Off: Backlight set to 0 mA + 1Level 1: daylight + 2Level 2: bright + 3Level 3: office + 4Level 4: indoor + 5Level 5: dark + ==== + + Writing 0 returns to normal/automatic ambient light level + operation. + + It can be enabled by writing the value stored in + /sys/class/backlight//max_brightness to + /sys/class/backlight//brightness. diff --git a/Documentation/ABI/testing/sysfs-class-backlight-adp8860 b/Documentation/ABI/testing/sysfs-class-backlight-adp8860 index 54d61c788b1b..6610ac73f9ba 100644 --- a/Documentation/ABI/testing/sysfs-class-backlight-adp8860 +++ b/Documentation/ABI/testing/sysfs-class-backlight-adp8860 @@ -6,25 +6,8 @@ adp8860, adp8861 and adp8863 devices: daylight (level 1), office (level 2) and dark (level 3). By default the brightness operates at the daylight brightness level. -What: /sys/class/backlight//ambient_light_level -Date: Apr, 2010 -KernelVersion: v2.6.35 -Contact: Michael Hennerich -Description: - (RO) 13-bit conversion value for the first light sensor—high - byte (Bit 12 to Bit 8). The value is updated every 80 ms (when - the light sensor is enabled). - - -What: /sys/class/backlight//ambient_light_zone -Date: Apr, 2010 -KernelVersion: v2.6.35 -Contact: Micha
[PATCH v2 39/39] scripts: get_abi.pl: assume ReST format by default
All ABI files are now compatible with ReST format. So, change the script default to assume that the ABI source files are compatible with ReST. Signed-off-by: Mauro Carvalho Chehab --- scripts/get_abi.pl | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/scripts/get_abi.pl b/scripts/get_abi.pl index d09bb37dd236..2cb592f8eba4 100755 --- a/scripts/get_abi.pl +++ b/scripts/get_abi.pl @@ -18,7 +18,7 @@ my $prefix="Documentation/ABI"; # # If true, assumes that the description is formatted with ReST # -my $description_is_rst = 0; +my $description_is_rst = 1; GetOptions( "debug|d+" => \$debug, -- 2.26.2
[PATCH v2 17/39] docs: add ABI documentation to the admin-guide book
As we don't want a generic Sphinx extension to execute commands, change the one proposed to Markus to call the abi_book.pl script. Use a script to parse the Documentation/ABI directory and output it at the admin-guide. Signed-off-by: Mauro Carvalho Chehab --- Documentation/admin-guide/abi-obsolete.rst | 10 ++ Documentation/admin-guide/abi-removed.rst | 4 Documentation/admin-guide/abi-stable.rst | 13 + Documentation/admin-guide/abi-testing.rst | 19 +++ Documentation/admin-guide/abi.rst | 11 +++ Documentation/admin-guide/index.rst| 2 ++ Documentation/conf.py | 3 ++- 7 files changed, 61 insertions(+), 1 deletion(-) create mode 100644 Documentation/admin-guide/abi-obsolete.rst create mode 100644 Documentation/admin-guide/abi-removed.rst create mode 100644 Documentation/admin-guide/abi-stable.rst create mode 100644 Documentation/admin-guide/abi-testing.rst create mode 100644 Documentation/admin-guide/abi.rst diff --git a/Documentation/admin-guide/abi-obsolete.rst b/Documentation/admin-guide/abi-obsolete.rst new file mode 100644 index ..cda9168445a5 --- /dev/null +++ b/Documentation/admin-guide/abi-obsolete.rst @@ -0,0 +1,10 @@ +ABI obsolete symbols + + +Documents interfaces that are still remaining in the kernel, but are +marked to be removed at some later point in time. + +The description of the interface will document the reason why it is +obsolete and when it can be expected to be removed. + +.. kernel-abi:: $srctree/Documentation/ABI/obsolete diff --git a/Documentation/admin-guide/abi-removed.rst b/Documentation/admin-guide/abi-removed.rst new file mode 100644 index ..497978fc9632 --- /dev/null +++ b/Documentation/admin-guide/abi-removed.rst @@ -0,0 +1,4 @@ +ABI removed symbols +=== + +.. kernel-abi:: $srctree/Documentation/ABI/removed diff --git a/Documentation/admin-guide/abi-stable.rst b/Documentation/admin-guide/abi-stable.rst new file mode 100644 index ..7495d7a35048 --- /dev/null +++ b/Documentation/admin-guide/abi-stable.rst @@ -0,0 +1,13 @@ +ABI stable symbols +== + +Documents the interfaces that the developer has defined to be stable. + +Userspace programs are free to use these interfaces with no +restrictions, and backward compatibility for them will be guaranteed +for at least 2 years. + +Most interfaces (like syscalls) are expected to never change and always +be available. + +.. kernel-abi:: $srctree/Documentation/ABI/stable diff --git a/Documentation/admin-guide/abi-testing.rst b/Documentation/admin-guide/abi-testing.rst new file mode 100644 index ..5c886fc50b9e --- /dev/null +++ b/Documentation/admin-guide/abi-testing.rst @@ -0,0 +1,19 @@ +ABI testing symbols +=== + +Documents interfaces that are felt to be stable, +as the main development of this interface has been completed. + +The interface can be changed to add new features, but the +current interface will not break by doing this, unless grave +errors or security problems are found in them. + +Userspace programs can start to rely on these interfaces, but they must +be aware of changes that can occur before these interfaces move to +be marked stable. + +Programs that use these interfaces are strongly encouraged to add their +name to the description of these interfaces, so that the kernel +developers can easily notify them if any changes occur. + +.. kernel-abi:: $srctree/Documentation/ABI/testing diff --git a/Documentation/admin-guide/abi.rst b/Documentation/admin-guide/abi.rst new file mode 100644 index ..3b9645c77469 --- /dev/null +++ b/Documentation/admin-guide/abi.rst @@ -0,0 +1,11 @@ += +Linux ABI description += + +.. toctree:: + :maxdepth: 1 + + abi-stable + abi-testing + abi-obsolete + abi-removed diff --git a/Documentation/admin-guide/index.rst b/Documentation/admin-guide/index.rst index ed1cf94ea50c..4e0c4ae44acd 100644 --- a/Documentation/admin-guide/index.rst +++ b/Documentation/admin-guide/index.rst @@ -18,6 +18,8 @@ etc. devices sysctl/index + abi + This section describes CPU vulnerabilities and their mitigations. .. toctree:: diff --git a/Documentation/conf.py b/Documentation/conf.py index 7ee05fd4cb17..ed2b43ec7754 100644 --- a/Documentation/conf.py +++ b/Documentation/conf.py @@ -38,7 +38,8 @@ needs_sphinx = '1.3' # ones. extensions = ['kerneldoc', 'rstFlatTable', 'kernel_include', 'kfigure', 'sphinx.ext.ifconfig', 'automarkup', - 'maintainers_include', 'sphinx.ext.autosectionlabel' ] + 'maintainers_include', 'sphinx.ext.autosectionlabel', + 'kernel_abi'] # # cdomain is badly broken in Sphinx 3+. Leaving it out generates *most* -- 2.26.2
[PATCH v2 33/39] docs: ABI: stable: remove a duplicated documentation
Perhaps due to a wrong cut-and-paste, this entry:
What: /sys/bus/vmbus/devices//channels//cpu
was added twice by the same patch, one following the other.
Remove the duplication.
Fixes: c2e5df616e1a ("vmbus: add per-channel sysfs info")
Acked-by: Wei Liu
Signed-off-by: Mauro Carvalho Chehab
---
Documentation/ABI/stable/sysfs-bus-vmbus | 7 ---
1 file changed, 7 deletions(-)
diff --git a/Documentation/ABI/stable/sysfs-bus-vmbus
b/Documentation/ABI/stable/sysfs-bus-vmbus
index 8e8d167eca31..c27b7b89477c 100644
--- a/Documentation/ABI/stable/sysfs-bus-vmbus
+++ b/Documentation/ABI/stable/sysfs-bus-vmbus
@@ -63,13 +63,6 @@ Contact: Stephen Hemminger
Description: VCPU (sub)channel is affinitized to
Users: tools/hv/lsvmbus and other debugging tools
-What: /sys/bus/vmbus/devices//channels//cpu
-Date: September. 2017
-KernelVersion: 4.14
-Contact: Stephen Hemminger
-Description: VCPU (sub)channel is affinitized to
-Users: tools/hv/lsvmbus and other debugging tools
-
What: /sys/bus/vmbus/devices//channels//in_mask
Date: September. 2017
KernelVersion: 4.14
--
2.26.2
[PATCH v2 26/39] docs: Kconfig/Makefile: add a check for broken ABI files
The files under Documentation/ABI should follow the syntax
as defined at Documentation/ABI/README.
Allow checking if they're following the syntax by running
the ABI parser script on COMPILE_TEST.
With that, when there's a problem with a file under
Documentation/ABI, it would produce a warning like:
Warning: file
./Documentation/ABI/testing/sysfs-bus-pci-devices-aer_stats#14:
What
'/sys/bus/pci/devices//aer_stats/aer_rootport_total_err_cor' doesn't have
a description
Warning: file
./Documentation/ABI/testing/sysfs-bus-pci-devices-aer_stats#21:
What
'/sys/bus/pci/devices//aer_stats/aer_rootport_total_err_fatal' doesn't
have a description
Signed-off-by: Mauro Carvalho Chehab
---
Documentation/Kconfig | 10 ++
Documentation/Makefile | 5 +
lib/Kconfig.debug | 2 ++
scripts/get_abi.pl | 14 +++---
4 files changed, 28 insertions(+), 3 deletions(-)
diff --git a/Documentation/Kconfig b/Documentation/Kconfig
index 66046fa1c341..e549a61f4d96 100644
--- a/Documentation/Kconfig
+++ b/Documentation/Kconfig
@@ -10,4 +10,14 @@ config WARN_MISSING_DOCUMENTS
If unsure, select 'N'.
+config WARN_ABI_ERRORS
+ bool "Warn if there are errors at ABI files"
+ depends on COMPILE_TEST
+ help
+ The files under Documentation/ABI should follow what's
+ described at Documentation/ABI/README. Yet, as they're manually
+ written, it would be possible that some of those files would
+ have errors that would break them for being parsed by
+ scripts/get_abi.pl. Add a check to verify them.
+ If unsure, select 'N'.
diff --git a/Documentation/Makefile b/Documentation/Makefile
index 4e47dff8b315..61a7310b49e0 100644
--- a/Documentation/Makefile
+++ b/Documentation/Makefile
@@ -10,6 +10,11 @@ ifeq ($(CONFIG_WARN_MISSING_DOCUMENTS),y)
$(shell $(srctree)/scripts/documentation-file-ref-check --warn)
endif
+# Check for broken ABI files
+ifeq ($(CONFIG_WARN_ABI_ERRORS),y)
+$(shell $(srctree)/scripts/get_abi.pl validate --dir
$(srctree)/Documentation/ABI)
+endif
+
# You can set these variables from the command line.
SPHINXBUILD = sphinx-build
SPHINXOPTS=
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index 537cf3c2937d..60f92c14d496 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -2449,4 +2449,6 @@ config HYPERV_TESTING
endmenu # "Kernel Testing and Coverage"
+source "Documentation/Kconfig"
+
endmenu # Kernel hacking
diff --git a/scripts/get_abi.pl b/scripts/get_abi.pl
index ff4f9f82ecad..f6adf4b38a2b 100755
--- a/scripts/get_abi.pl
+++ b/scripts/get_abi.pl
@@ -50,7 +50,15 @@ my %symbols;
sub parse_error() {
my ($file, $ln, $msg, $data) = @_;
- print STDERR "file $file#$ln: $msg at\n\t$data";
+ $data =~ s/\s+$/\n/;
+
+ print STDERR "Warning: file $file#$ln:\n\t$msg";
+
+ if ($data ne "") {
+ print STDERR ". Line\n\t\t$data";
+ } else {
+ print STDERR "\n";
+ }
}
#
@@ -110,7 +118,7 @@ sub parse_abi {
# Invalid, but it is a common mistake
if ($new_tag eq "where") {
- parse_error($file, $ln, "tag 'Where' is
invalid. Should be 'What:' instead", $_);
+ parse_error($file, $ln, "tag 'Where' is
invalid. Should be 'What:' instead", "");
$new_tag = "what";
}
@@ -225,7 +233,7 @@ sub parse_abi {
}
# Everything else is error
- parse_error($file, $ln, "Unexpected line:", $_);
+ parse_error($file, $ln, "Unexpected content", $_);
}
$data{$nametag}->{description} =~ s/^\n+// if
($data{$nametag}->{description});
if ($what) {
--
2.26.2
[PATCH v2 25/39] docs: abi-testing.rst: enable --rst-sources when building docs
Now that ABI/testing documents were fixed, add --rst-sources to the ABI/testing too. Signed-off-by: Mauro Carvalho Chehab --- Documentation/admin-guide/abi-testing.rst | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/admin-guide/abi-testing.rst b/Documentation/admin-guide/abi-testing.rst index 5c886fc50b9e..b205b16a72d0 100644 --- a/Documentation/admin-guide/abi-testing.rst +++ b/Documentation/admin-guide/abi-testing.rst @@ -17,3 +17,4 @@ name to the description of these interfaces, so that the kernel developers can easily notify them if any changes occur. .. kernel-abi:: $srctree/Documentation/ABI/testing + :rst: -- 2.26.2
[PATCH v2 27/39] docs: ABI: convert testing/configfs-acpi to ReST
There are some problems with this file when a ReST content is produced. Fix it. Signed-off-by: Mauro Carvalho Chehab --- Documentation/ABI/testing/configfs-acpi | 34 ++--- 1 file changed, 25 insertions(+), 9 deletions(-) diff --git a/Documentation/ABI/testing/configfs-acpi b/Documentation/ABI/testing/configfs-acpi index 4ab4e99aa863..c09b640c3cb1 100644 --- a/Documentation/ABI/testing/configfs-acpi +++ b/Documentation/ABI/testing/configfs-acpi @@ -14,7 +14,8 @@ Description: This group contains the configuration for user defined ACPI tables. The attributes of a user define table are: - aml - a binary attribute that the user can use to + aml + - a binary attribute that the user can use to fill in the ACPI aml definitions. Once the aml data is written to this file and the file is closed the table will be loaded and ACPI devices @@ -26,11 +27,26 @@ Description: The rest of the attributes are read-only and are valid only after the table has been loaded by filling the aml entry: - signature - ASCII table signature - length - length of table in bytes, including the header - revision- ACPI Specification minor version number - oem_id - ASCII OEM identification - oem_table_id- ASCII OEM table identification - oem_revision- OEM revision number - asl_compiler_id - ASCII ASL compiler vendor ID - asl_compiler_revision - ASL compiler version + signature + - ASCII table signature + + length + - length of table in bytes, including the header + + revision + - ACPI Specification minor version number + + oem_id + - ASCII OEM identification + + oem_table_id + - ASCII OEM table identification + + oem_revision + - OEM revision number + + asl_compiler_id + - ASCII ASL compiler vendor ID + + asl_compiler_revision + - ASL compiler version -- 2.26.2
[PATCH v2 22/39] docs: ABI: make it parse ABI/stable as ReST-compatible files
Now that the stable ABI files are compatible with ReST,
parse them without converting complex descriptions as literal
blocks nor escaping special characters.
Please notice that escaping special characters will probably
be needed at descriptions, at least for the asterisk character.
Signed-off-by: Mauro Carvalho Chehab
---
Documentation/admin-guide/abi-stable.rst | 1 +
Documentation/sphinx/kernel_abi.py | 8 ++--
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/Documentation/admin-guide/abi-stable.rst
b/Documentation/admin-guide/abi-stable.rst
index 7495d7a35048..70490736e0d3 100644
--- a/Documentation/admin-guide/abi-stable.rst
+++ b/Documentation/admin-guide/abi-stable.rst
@@ -11,3 +11,4 @@ Most interfaces (like syscalls) are expected to never change
and always
be available.
.. kernel-abi:: $srctree/Documentation/ABI/stable
+ :rst:
diff --git a/Documentation/sphinx/kernel_abi.py
b/Documentation/sphinx/kernel_abi.py
index ce5f3b0ae811..f3da859c9878 100644
--- a/Documentation/sphinx/kernel_abi.py
+++ b/Documentation/sphinx/kernel_abi.py
@@ -73,12 +73,13 @@ class KernelCmd(Directive):
u"""KernelABI (``kernel-abi``) directive"""
required_arguments = 1
-optional_arguments = 0
+optional_arguments = 2
has_content = False
final_argument_whitespace = True
option_spec = {
-"debug" : directives.flag
+"debug" : directives.flag,
+"rst" : directives.unchanged
}
def run(self):
@@ -92,6 +93,9 @@ class KernelCmd(Directive):
cmd = "get_abi.pl rest --enable-lineno --dir "
cmd += self.arguments[0]
+if 'rst' in self.options:
+cmd += " --rst-source"
+
srctree = path.abspath(os.environ["srctree"])
fname = cmd
--
2.26.2
[PATCH v2 29/39] docs: ABI: vdso: use the right format for ABI
This ABI is not following the format described at ABI/README. Use it, filling in the blanks with the git log that added it, and using the current e-mail from Andy. Signed-off-by: Mauro Carvalho Chehab --- Documentation/ABI/stable/vdso | 6 ++ 1 file changed, 6 insertions(+) diff --git a/Documentation/ABI/stable/vdso b/Documentation/ABI/stable/vdso index 73ed1240a5c0..951838d42781 100644 --- a/Documentation/ABI/stable/vdso +++ b/Documentation/ABI/stable/vdso @@ -1,3 +1,9 @@ +What: vDSO +Date: July 2011 +KernelVersion: 3.0 +Contact: Andy Lutomirski +Description: + On some architectures, when the kernel loads any userspace program it maps an ELF DSO into that program's address space. This DSO is called the vDSO and it often contains useful and highly-optimized alternatives -- 2.26.2
[PATCH v2 23/39] docs: ABI: create a 2-depth index for ABI
That helps to identify what ABI files are adding titles. Signed-off-by: Mauro Carvalho Chehab --- Documentation/admin-guide/abi.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/admin-guide/abi.rst b/Documentation/admin-guide/abi.rst index 3b9645c77469..bcab3ef2597c 100644 --- a/Documentation/admin-guide/abi.rst +++ b/Documentation/admin-guide/abi.rst @@ -3,7 +3,7 @@ Linux ABI description = .. toctree:: - :maxdepth: 1 + :maxdepth: 2 abi-stable abi-testing -- 2.26.2
[PATCH v2 24/39] docs: ABI: don't escape ReST-incompatible chars from obsolete and removed
With just a single fix, the contents there can be parsed properly without the need to escape any ReST incompatible stuff. Signed-off-by: Mauro Carvalho Chehab --- Documentation/ABI/obsolete/sysfs-gpio | 2 ++ Documentation/admin-guide/abi-obsolete.rst | 1 + Documentation/admin-guide/abi-removed.rst | 1 + 3 files changed, 4 insertions(+) diff --git a/Documentation/ABI/obsolete/sysfs-gpio b/Documentation/ABI/obsolete/sysfs-gpio index e0d4e5e2dd90..b8b0fd341c17 100644 --- a/Documentation/ABI/obsolete/sysfs-gpio +++ b/Documentation/ABI/obsolete/sysfs-gpio @@ -13,6 +13,8 @@ Description: GPIOs are identified as they are inside the kernel, using integers in the range 0..INT_MAX. See Documentation/admin-guide/gpio for more information. + :: + /sys/class/gpio /export ... asks the kernel to export a GPIO to userspace /unexport ... to return a GPIO to the kernel diff --git a/Documentation/admin-guide/abi-obsolete.rst b/Documentation/admin-guide/abi-obsolete.rst index cda9168445a5..d095867899c5 100644 --- a/Documentation/admin-guide/abi-obsolete.rst +++ b/Documentation/admin-guide/abi-obsolete.rst @@ -8,3 +8,4 @@ The description of the interface will document the reason why it is obsolete and when it can be expected to be removed. .. kernel-abi:: $srctree/Documentation/ABI/obsolete + :rst: diff --git a/Documentation/admin-guide/abi-removed.rst b/Documentation/admin-guide/abi-removed.rst index 497978fc9632..f7e9e43023c1 100644 --- a/Documentation/admin-guide/abi-removed.rst +++ b/Documentation/admin-guide/abi-removed.rst @@ -2,3 +2,4 @@ ABI removed symbols === .. kernel-abi:: $srctree/Documentation/ABI/removed + :rst: -- 2.26.2
[PATCH v2 30/39] docs: ABI: sysfs-bus-nvdimm: use the right format for ABI
This ABI is not following the format described at ABI/README. Use it, filling in the blanks with the git log that added it, and using the current e-mail from Dan. Signed-off-by: Mauro Carvalho Chehab --- Documentation/ABI/testing/sysfs-bus-nvdimm | 6 ++ 1 file changed, 6 insertions(+) diff --git a/Documentation/ABI/testing/sysfs-bus-nvdimm b/Documentation/ABI/testing/sysfs-bus-nvdimm index d64380262be8..bff84a16812a 100644 --- a/Documentation/ABI/testing/sysfs-bus-nvdimm +++ b/Documentation/ABI/testing/sysfs-bus-nvdimm @@ -1,2 +1,8 @@ +What: nvdimm +Date: July 2020 +KernelVersion: 5.8 +Contact: Dan Williams +Description: + The libnvdimm sub-system implements a common sysfs interface for platform nvdimm resources. See Documentation/driver-api/nvdimm/. -- 2.26.2
[PATCH v2 36/39] docs: ABI: sysfs-c2port: remove a duplicated entry
As warned by scripts/get_abi.pl:
Warning: /sys/class/c2port/c2portX/flash_erase is defined 2 times:
Documentation/ABI/testing/sysfs-c2port:60
Documentation/ABI/testing/sysfs-c2port:68
This entry was added twice at the same patch. Probalby a
cut-and paste issue.
Fixes: 4e17e1db9647 ("Add c2 port support")
Signed-off-by: Mauro Carvalho Chehab
---
Documentation/ABI/testing/sysfs-c2port | 7 ---
1 file changed, 7 deletions(-)
diff --git a/Documentation/ABI/testing/sysfs-c2port
b/Documentation/ABI/testing/sysfs-c2port
index 716cffc457e9..f7b8cf6e4398 100644
--- a/Documentation/ABI/testing/sysfs-c2port
+++ b/Documentation/ABI/testing/sysfs-c2port
@@ -66,13 +66,6 @@ Description:
the "erase" command on the on-board flash of the connected
micro.
-What: /sys/class/c2port/c2portX/flash_erase
-Date: October 2008
-Contact: Rodolfo Giometti
-Description:
- The /sys/class/c2port/c2portX/flash_erase file show the
- on-board flash size of the connected micro.
-
What: /sys/class/c2port/c2portX/reset
Date: October 2008
Contact: Rodolfo Giometti
--
2.26.2
[PATCH v2 21/39] docs: ABI: sysfs-uevent: make it compatible with ReST output
- Replace " by ``, in order to use monospaced fonts;
- mark literal blocks as such.
Signed-off-by: Mauro Carvalho Chehab
---
Documentation/ABI/testing/sysfs-uevent | 28 +++---
1 file changed, 16 insertions(+), 12 deletions(-)
diff --git a/Documentation/ABI/testing/sysfs-uevent
b/Documentation/ABI/testing/sysfs-uevent
index aa39f8d7bcdf..0b6227706b35 100644
--- a/Documentation/ABI/testing/sysfs-uevent
+++ b/Documentation/ABI/testing/sysfs-uevent
@@ -6,42 +6,46 @@ Description:
Enable passing additional variables for synthetic uevents that
are generated by writing /sys/.../uevent file.
-Recognized extended format is ACTION [UUID [KEY=VALUE ...].
+Recognized extended format is::
-The ACTION is compulsory - it is the name of the uevent action
-("add", "change", "remove"). There is no change compared to
-previous functionality here. The rest of the extended format
-is optional.
+ ACTION [UUID [KEY=VALUE ...]
+
+The ACTION is compulsory - it is the name of the uevent
+action (``add``, ``change``, ``remove``). There is no change
+compared to previous functionality here. The rest of the
+extended format is optional.
You need to pass UUID first before any KEY=VALUE pairs.
-The UUID must be in "----"
+The UUID must be in ``----``
format where 'x' is a hex digit. The UUID is considered to be
a transaction identifier so it's possible to use the same UUID
value for one or more synthetic uevents in which case we
logically group these uevents together for any userspace
listeners. The UUID value appears in uevent as
-"SYNTH_UUID=----" environment
+``SYNTH_UUID=----`` environment
variable.
If UUID is not passed in, the generated synthetic uevent gains
-"SYNTH_UUID=0" environment variable automatically.
+``SYNTH_UUID=0`` environment variable automatically.
The KEY=VALUE pairs can contain alphanumeric characters only.
+
It's possible to define zero or more pairs - each pair is then
delimited by a space character ' '. Each pair appears in
-synthetic uevent as "SYNTH_ARG_KEY=VALUE". That means the KEY
-name gains "SYNTH_ARG_" prefix to avoid possible collisions
+synthetic uevent as ``SYNTH_ARG_KEY=VALUE``. That means the KEY
+name gains ``SYNTH_ARG_`` prefix to avoid possible collisions
with existing variables.
-Example of valid sequence written to the uevent file:
+Example of valid sequence written to the uevent file::
add fe4d7c9d-b8c6-4a70-9ef1-3d8a58d18eed A=1 B=abc
-This generates synthetic uevent including these variables:
+This generates synthetic uevent including these variables::
ACTION=add
SYNTH_ARG_A=1
SYNTH_ARG_B=abc
SYNTH_UUID=fe4d7c9d-b8c6-4a70-9ef1-3d8a58d18eed
+
Users:
udev, userspace tools generating synthetic uevents
--
2.26.2
[PATCH v2 08/39] scripts: get_abi.pl: prevent duplicated file names
The same filename may exist on multiple directories within
ABI. Create separate entries at the internal database for
each of them.
Signed-off-by: Mauro Carvalho Chehab
---
scripts/get_abi.pl | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/scripts/get_abi.pl b/scripts/get_abi.pl
index e5a5588a8639..5612f019fae0 100755
--- a/scripts/get_abi.pl
+++ b/scripts/get_abi.pl
@@ -65,7 +65,10 @@ sub parse_abi {
my $name = $file;
$name =~ s,.*/,,;
- my $nametag = "File $name";
+ my $fn = $file;
+ $fn =~ s,Documentation/ABI/,,;
+
+ my $nametag = "File $fn";
$data{$nametag}->{what} = "File $name";
$data{$nametag}->{type} = "File";
$data{$nametag}->{file} = $name;
@@ -320,16 +323,18 @@ sub output_rest {
my $fileref = "abi_file_".$path;
if ($type eq "File") {
- my $bar = $w;
- $bar =~ s/./-/g;
-
print ".. _$fileref:\n\n";
- print "$w\n$bar\n\n";
} else {
print "Defined on file :ref:`$f
<$fileref>`\n\n";
}
}
+ if ($type eq "File") {
+ my $bar = $w;
+ $bar =~ s/./-/g;
+ print "$w\n$bar\n\n";
+ }
+
my $desc = "";
$desc = $data{$what}->{description} if
(defined($data{$what}->{description}));
$desc =~ s/\s+$/\n/;
--
2.26.2
[PATCH v2 15/39] docs: kernel_abi.py: use --enable-lineno for get_abi.pl
Just like kernel-doc extension, we need to be able to identify
what part of an imported document has issues, as reporting them
as:
get_abi.pl rest --dir $srctree/Documentation/ABI/obsolete
--rst-source:1689: ERROR: Unexpected indentation.
Makes a lot harder for someone to fix.
It should be noticed that it the line which will be reported is
the line where the "What:" definition is, and not the line
with actually has an error.
Signed-off-by: Mauro Carvalho Chehab
---
Documentation/sphinx/kernel_abi.py | 18 ++
1 file changed, 14 insertions(+), 4 deletions(-)
diff --git a/Documentation/sphinx/kernel_abi.py
b/Documentation/sphinx/kernel_abi.py
index 8601a3b75a28..096dec482e96 100644
--- a/Documentation/sphinx/kernel_abi.py
+++ b/Documentation/sphinx/kernel_abi.py
@@ -36,6 +36,7 @@ import codecs
import os
import subprocess
import sys
+import re
from os import path
@@ -93,7 +94,7 @@ class KernelCmd(Directive):
env = doc.settings.env
cwd = path.dirname(doc.current_source)
-cmd = "get_abi.pl rest --dir "
+cmd = "get_abi.pl rest --enable-lineno --dir "
cmd += self.arguments[0]
srctree = path.abspath(os.environ["srctree"])
@@ -137,7 +138,7 @@ class KernelCmd(Directive):
% (self.name, ErrorString(exc)))
return out
-def nestedParse(self, lines, fname):
+def nestedParse(self, lines, f):
content = ViewList()
node= nodes.section()
@@ -147,8 +148,17 @@ class KernelCmd(Directive):
code_block += "\n" + l
lines = code_block + "\n\n"
-for c, l in enumerate(lines.split("\n")):
-content.append(l, fname, c)
+line_regex = re.compile("^#define LINENO (\S+)\#([0-9]+)$")
+ln = 0
+
+for line in lines.split("\n"):
+match = line_regex.search(line)
+if match:
+f = match.group(1)
+# sphinx counts lines from 0
+ln = int(match.group(2)) - 1
+else:
+content.append(line, f, ln)
buf = self.state.memo.title_styles, self.state.memo.section_level,
self.state.memo.reporter
--
2.26.2
[PATCH v2 16/39] docs: kernel_abi.py: Handle with a lazy Sphinx parser
The Sphinx docutils parser is lazy: if the content is bigger than
a certain number of lines, it silenlty stops parsing it,
producing an incomplete content. This seems to be worse on newer
Sphinx versions, like 2.0.
So, change the logic to parse the contents per input file.
Signed-off-by: Mauro Carvalho Chehab
---
Documentation/sphinx/kernel_abi.py | 39 --
1 file changed, 26 insertions(+), 13 deletions(-)
diff --git a/Documentation/sphinx/kernel_abi.py
b/Documentation/sphinx/kernel_abi.py
index 096dec482e96..ce5f3b0ae811 100644
--- a/Documentation/sphinx/kernel_abi.py
+++ b/Documentation/sphinx/kernel_abi.py
@@ -37,6 +37,7 @@ import os
import subprocess
import sys
import re
+import kernellog
from os import path
@@ -80,12 +81,6 @@ class KernelCmd(Directive):
"debug" : directives.flag
}
-def warn(self, message, **replace):
-replace["fname"] = self.state.document.current_source
-replace["line_no"] = replace.get("line_no", self.lineno)
-message = ("%(fname)s:%(line_no)s: [kernel-abi WARN] : " + message) %
replace
-self.state.document.settings.env.app.warn(message, prefix="")
-
def run(self):
doc = self.state.document
@@ -111,7 +106,7 @@ class KernelCmd(Directive):
shell_env["srctree"] = srctree
lines = self.runCmd(cmd, shell=True, cwd=cwd, env=shell_env)
-nodeList = self.nestedParse(lines, fname)
+nodeList = self.nestedParse(lines, self.arguments[0])
return nodeList
def runCmd(self, cmd, **kwargs):
@@ -138,9 +133,9 @@ class KernelCmd(Directive):
% (self.name, ErrorString(exc)))
return out
-def nestedParse(self, lines, f):
+def nestedParse(self, lines, fname):
content = ViewList()
-node= nodes.section()
+node = nodes.section()
if "debug" in self.options:
code_block = "\n\n.. code-block:: rst\n:linenos:\n"
@@ -150,22 +145,42 @@ class KernelCmd(Directive):
line_regex = re.compile("^#define LINENO (\S+)\#([0-9]+)$")
ln = 0
+n = 0
+f = fname
for line in lines.split("\n"):
+n = n + 1
match = line_regex.search(line)
if match:
-f = match.group(1)
+new_f = match.group(1)
+
+# Sphinx parser is lazy: it stops parsing contents in the
+# middle, if it is too big. So, handle it per input file
+if new_f != f and content:
+self.do_parse(content, node)
+content = ViewList()
+
+f = new_f
+
# sphinx counts lines from 0
ln = int(match.group(2)) - 1
else:
content.append(line, f, ln)
-buf = self.state.memo.title_styles, self.state.memo.section_level,
self.state.memo.reporter
+kernellog.info(self.state.document.settings.env.app, "%s: parsed %i
lines" % (fname, n))
+if content:
+self.do_parse(content, node)
+
+return node.children
+
+def do_parse(self, content, node):
if Use_SSI:
with switch_source_input(self.state, content):
self.state.nested_parse(content, 0, node, match_titles=1)
else:
+buf = self.state.memo.title_styles,
self.state.memo.section_level, self.state.memo.reporter
+
self.state.memo.title_styles = []
self.state.memo.section_level = 0
self.state.memo.reporter = AutodocReporter(content,
self.state.memo.reporter)
@@ -173,5 +188,3 @@ class KernelCmd(Directive):
self.state.nested_parse(content, 0, node, match_titles=1)
finally:
self.state.memo.title_styles, self.state.memo.section_level,
self.state.memo.reporter = buf
-
-return node.children
--
2.26.2
[PATCH v2 18/39] docs: ABI: README: specify that files should be ReST compatible
As we plan to remove the escaping code from the scripts/get_abi.pl, specify at the ABI README file that the content of the file should be ReST compatible. Signed-off-by: Mauro Carvalho Chehab --- Documentation/ABI/README | 10 +- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/Documentation/ABI/README b/Documentation/ABI/README index 3121029dce21..8bac9cb09a6d 100644 --- a/Documentation/ABI/README +++ b/Documentation/ABI/README @@ -32,7 +32,7 @@ The different levels of stability are: layout of the files below for details on how to do this.) obsolete/ - This directory documents interfaces that are still remaining in + This directory documents interfaces that are still remaining in the kernel, but are marked to be removed at some later point in time. The description of the interface will document the reason why it is obsolete and when it can be expected to be removed. @@ -58,6 +58,14 @@ Users: All users of this interface who wish to be notified when be changed further. +Note: + The fields should be use a simple notation, compatible with ReST markup. + Also, the file **should not** have a top-level index, like:: + + === + foo + === + How things move between levels: Interfaces in stable may move to obsolete, as long as the proper -- 2.26.2
[PATCH v2 14/39] docs: kernel_abi.py: make it compatible with Sphinx 1.7+
The same way kerneldoc.py needed changes to work with newer Sphinx, this script needs the same changes. While here, reorganize the include order to match kerneldoc.py. Signed-off-by: Mauro Carvalho Chehab --- Documentation/sphinx/kernel_abi.py | 39 +- 1 file changed, 27 insertions(+), 12 deletions(-) diff --git a/Documentation/sphinx/kernel_abi.py b/Documentation/sphinx/kernel_abi.py index fe69c213716d..8601a3b75a28 100644 --- a/Documentation/sphinx/kernel_abi.py +++ b/Documentation/sphinx/kernel_abi.py @@ -33,18 +33,27 @@ u""" """ import codecs -import sys import os -from os import path import subprocess +import sys -from sphinx.ext.autodoc import AutodocReporter +from os import path -from docutils import nodes -from docutils.parsers.rst import Directive, directives +from docutils import nodes, statemachine from docutils.statemachine import ViewList +from docutils.parsers.rst import directives, Directive from docutils.utils.error_reporting import ErrorString +# +# AutodocReporter is only good up to Sphinx 1.7 +# +import sphinx + +Use_SSI = sphinx.__version__[:3] >= '1.7' +if Use_SSI: +from sphinx.util.docutils import switch_source_input +else: +from sphinx.ext.autodoc import AutodocReporter __version__ = '1.0' @@ -142,11 +151,17 @@ class KernelCmd(Directive): content.append(l, fname, c) buf = self.state.memo.title_styles, self.state.memo.section_level, self.state.memo.reporter -self.state.memo.title_styles = [] -self.state.memo.section_level = 0 -self.state.memo.reporter = AutodocReporter(content, self.state.memo.reporter) -try: -self.state.nested_parse(content, 0, node, match_titles=1) -finally: -self.state.memo.title_styles, self.state.memo.section_level, self.state.memo.reporter = buf + +if Use_SSI: +with switch_source_input(self.state, content): +self.state.nested_parse(content, 0, node, match_titles=1) +else: +self.state.memo.title_styles = [] +self.state.memo.section_level = 0 +self.state.memo.reporter = AutodocReporter(content, self.state.memo.reporter) +try: +self.state.nested_parse(content, 0, node, match_titles=1) +finally: +self.state.memo.title_styles, self.state.memo.section_level, self.state.memo.reporter = buf + return node.children -- 2.26.2
[PATCH v2 13/39] docs: kernel_abi.py: fix UTF-8 support
The parser breaks with UTF-8 characters with Sphinx 1.4.
Signed-off-by: Mauro Carvalho Chehab
---
Documentation/sphinx/kernel_abi.py | 19 +++
1 file changed, 7 insertions(+), 12 deletions(-)
diff --git a/Documentation/sphinx/kernel_abi.py
b/Documentation/sphinx/kernel_abi.py
index f8e7a02066c2..fe69c213716d 100644
--- a/Documentation/sphinx/kernel_abi.py
+++ b/Documentation/sphinx/kernel_abi.py
@@ -1,5 +1,7 @@
# -*- coding: utf-8; mode: python -*-
+# coding=utf-8
# SPDX-License-Identifier: GPL-2.0
+#
u"""
kernel-abi
~~
@@ -30,6 +32,7 @@ u"""
"""
+import codecs
import sys
import os
from os import path
@@ -45,14 +48,6 @@ from docutils.utils.error_reporting import ErrorString
__version__ = '1.0'
-# We can't assume that six is installed
-PY3 = sys.version_info[0] == 3
-PY2 = sys.version_info[0] == 2
-if PY3:
-# pylint: disable=C0103, W0622
-unicode = str
-basestring = str
-
def setup(app):
app.add_directive("kernel-abi", KernelCmd)
@@ -117,12 +112,12 @@ class KernelCmd(Directive):
cmd
, stdout = subprocess.PIPE
, stderr = subprocess.PIPE
-, universal_newlines = True
, **kwargs
)
out, err = proc.communicate()
-if err:
-self.warn(err)
+
+out, err = codecs.decode(out, 'utf-8'), codecs.decode(err, 'utf-8')
+
if proc.returncode != 0:
raise self.severe(
u"command '%s' failed with return code %d"
@@ -131,7 +126,7 @@ class KernelCmd(Directive):
except OSError as exc:
raise self.severe(u"problems with '%s' directive: %s."
% (self.name, ErrorString(exc)))
-return unicode(out)
+return out
def nestedParse(self, lines, fname):
content = ViewList()
--
2.26.2
[PATCH v2 07/39] scripts: get_abi.pl: output users in ReST format
Right now, the script only outputs Users on search. Print it
also in ReST format.
Signed-off-by: Mauro Carvalho Chehab
---
scripts/get_abi.pl | 8
1 file changed, 8 insertions(+)
diff --git a/scripts/get_abi.pl b/scripts/get_abi.pl
index 1d1408fad130..e5a5588a8639 100755
--- a/scripts/get_abi.pl
+++ b/scripts/get_abi.pl
@@ -371,6 +371,14 @@ sub output_rest {
print "- :ref:`$content <$label>`\n\n";
}
}
+
+ if (defined($data{$what}->{users})) {
+ my $users = $data{$what}->{users};
+
+ $users =~ s/\n/\n\t/g;
+ printf "Users:\n\t%s\n\n", $users if ($users ne "");
+ }
+
}
}
--
2.26.2
[PATCH v2 02/39] scripts: get_abi.pl: fix parsing on ReST mode
When the source ABI file is using ReST notation, the script
should handle whitespaces and lines with care, as otherwise
the file won't be properly recognized.
Address the bugs that are on such part of the script.
Signed-off-by: Mauro Carvalho Chehab
---
scripts/get_abi.pl | 30 ++
1 file changed, 14 insertions(+), 16 deletions(-)
diff --git a/scripts/get_abi.pl b/scripts/get_abi.pl
index 107672cdacb3..0c403af86fd5 100755
--- a/scripts/get_abi.pl
+++ b/scripts/get_abi.pl
@@ -151,7 +151,8 @@ sub parse_abi {
$content = $2;
}
while ($space =~ s/\t+/' ' x
(length($&) * 8 - length($`) % 8)/e) {}
- $data{$what}->{$tag} .= $content;
+
+ $data{$what}->{$tag} .= "$content\n" if
($content);
} else {
$data{$what}->{$tag} = $content;
}
@@ -166,31 +167,28 @@ sub parse_abi {
}
if ($tag eq "description") {
+ my $content = $_;
+ while ($content =~ s/\t+/' ' x (length($&) * 8 -
length($`) % 8)/e) {}
if (!$data{$what}->{description}) {
- s/^($space)//;
- if (m/^(\s*)(.*)/) {
- my $sp = $1;
- while ($sp =~ s/\t+/' ' x (length($&) *
8 - length($`) % 8)/e) {}
- my $content = "$sp$2";
-
- $content =~ s/^($space)//;
-
- $data{$what}->{$tag} .= "$content";
+ # Preserve initial spaces for the first line
+ if ($content =~ m/^(\s*)(.*)$/) {
+ $space = $1;
+ $content = $2;
}
+
+ $data{$what}->{$tag} .= "$content\n" if
($content);
} else {
- my $content = $_;
if (m/^\s*\n/) {
$data{$what}->{$tag} .= $content;
next;
}
- while ($content =~ s/\t+/' ' x (length($&) * 8
- length($`) % 8)/e) {}
$space = "" if (!($content =~ s/^($space)//));
- # Compress spaces with tabs
- $content =~ s<^ {8}> <\t>;
- $content =~ s<^ {1,7}\t> <\t>;
- $content =~ s< {1,7}\t> <\t>;
+# # Compress spaces with tabs
+# $content =~ s<^ {8}> <\t>;
+# $content =~ s<^ {1,7}\t> <\t>;
+# $content =~ s< {1,7}\t> <\t>;
$data{$what}->{$tag} .= $content;
}
next;
--
2.26.2
[PATCH v2 03/39] scripts: get_abi.pl: Allow optionally record from where a line came from
The get_abi.pl reads a lot of files and can join them on a
single output file. Store where each "What:" output came from,
in order to be able to optionally display it.
This is useful for the Sphinx extension, with can now be
able to blame what ABI file has issues, and on what line
the What: description with problems begin.
Signed-off-by: Mauro Carvalho Chehab
---
scripts/get_abi.pl | 22 +-
1 file changed, 21 insertions(+), 1 deletion(-)
diff --git a/scripts/get_abi.pl b/scripts/get_abi.pl
index 0c403af86fd5..6a4d387ebf3b 100755
--- a/scripts/get_abi.pl
+++ b/scripts/get_abi.pl
@@ -10,6 +10,7 @@ use Fcntl ':mode';
my $help;
my $man;
my $debug;
+my $enable_lineno;
my $prefix="Documentation/ABI";
#
@@ -19,6 +20,7 @@ my $description_is_rst = 0;
GetOptions(
"debug|d+" => \$debug,
+ "enable-lineno" => \$enable_lineno,
"rst-source!" => \$description_is_rst,
"dir=s" => \$prefix,
'help|?' => \$help,
@@ -67,6 +69,7 @@ sub parse_abi {
$data{$nametag}->{file} = $name;
$data{$nametag}->{filepath} = $file;
$data{$nametag}->{is_file} = 1;
+ $data{$nametag}->{line_no} = 1;
my $type = $file;
$type =~ s,.*/(.*)/.*,$1,;
@@ -126,6 +129,8 @@ sub parse_abi {
if ($tag ne "" && $new_tag) {
$tag = $new_tag;
+ $data{$what}->{line_no} = $ln;
+
if ($new_what) {
@{$data{$what}->{label}} = @labels if
($data{$nametag}->{what});
@labels = ();
@@ -221,6 +226,12 @@ sub output_rest {
my $file = $data{$what}->{file};
my $filepath = $data{$what}->{filepath};
+ if ($enable_lineno) {
+ printf "#define LINENO %s%s#%s\n\n",
+ $prefix, $data{$what}->{file},
+ $data{$what}->{line_no};
+ }
+
my $w = $what;
$w =~ s/([\(\)\_\-\*\=\^\~\\])/\\$1/g;
@@ -369,6 +380,10 @@ sub search_symbols {
}
}
+# Ensure that the prefix will always end with a slash
+# While this is not needed for find, it makes the patch nicer
+# with --enable-lineno
+$prefix =~ s,/?$,/,;
#
# Parses all ABI files located at $prefix dir
@@ -395,7 +410,8 @@ abi_book.pl - parse the Linux ABI files and produce a ReST
book.
=head1 SYNOPSIS
-B [--debug] [--man] [--help] --[(no-)rst-source] [--dir=]
[]
+B [--debug] [--enable-lineno] [--man] [--help]
+ [--(no-)rst-source] [--dir=] []
Where can be:
@@ -425,6 +441,10 @@ selecting between a rst-compliant source ABI
(--rst-source), or a
plain text that may be violating ReST spec, so it requres some escaping
logic (--no-rst-source).
+=item B<--enable-lineno>
+
+Enable output of #define LINENO lines.
+
=item B<--debug>
Put the script in verbose mode, useful for debugging. Can be called multiple
--
2.26.2
[PATCH v2 04/39] scripts: get_abi.pl: improve its parser to better catch up indentation
The original parser for indentation were relying on having
just one description for each "what". However, that's not
the case: there are a number of ABI symbols that got defined
multiple times.
Improve the parser for it to better handle descriptions
if entries are duplicated.
Signed-off-by: Mauro Carvalho Chehab
---
scripts/get_abi.pl | 42 +++---
1 file changed, 19 insertions(+), 23 deletions(-)
diff --git a/scripts/get_abi.pl b/scripts/get_abi.pl
index 6a4d387ebf3b..bd018eb3815b 100755
--- a/scripts/get_abi.pl
+++ b/scripts/get_abi.pl
@@ -147,17 +147,19 @@ sub parse_abi {
parse_error($file, $ln, "'What:' should
come first:", $_);
next;
}
- if ($tag eq "description") {
- # Preserve initial spaces for the first
line
+ if ($new_tag eq "description") {
+ $sep =~ s,:, ,;
$content = ' ' x length($new_tag) .
$sep . $content;
- $content =~ s,^(\s*):,$1 ,;
- if ($content =~ m/^(\s*)(.*)$/) {
+ while ($content =~ s/\t+/' ' x
(length($&) * 8 - length($`) % 8)/e) {}
+ if ($content =~ m/^(\s*)(\S.*)$/) {
+ # Preserve initial spaces for
the first line
$space = $1;
- $content = $2;
+ $content = "$2\n";
+ $data{$what}->{$tag} .=
$content;
+ } else {
+ undef($space);
}
- while ($space =~ s/\t+/' ' x
(length($&) * 8 - length($`) % 8)/e) {}
- $data{$what}->{$tag} .= "$content\n" if
($content);
} else {
$data{$what}->{$tag} = $content;
}
@@ -174,28 +176,22 @@ sub parse_abi {
if ($tag eq "description") {
my $content = $_;
while ($content =~ s/\t+/' ' x (length($&) * 8 -
length($`) % 8)/e) {}
- if (!$data{$what}->{description}) {
+ if (m/^\s*\n/) {
+ $data{$what}->{$tag} .= "\n";
+ next;
+ }
+
+ if (!defined($space)) {
# Preserve initial spaces for the first line
- if ($content =~ m/^(\s*)(.*)$/) {
+ if ($content =~ m/^(\s*)(\S.*)$/) {
$space = $1;
- $content = $2;
+ $content = "$2\n";
}
-
- $data{$what}->{$tag} .= "$content\n" if
($content);
} else {
- if (m/^\s*\n/) {
- $data{$what}->{$tag} .= $content;
- next;
- }
-
$space = "" if (!($content =~ s/^($space)//));
-
-# # Compress spaces with tabs
-# $content =~ s<^ {8}> <\t>;
-# $content =~ s<^ {1,7}\t> <\t>;
-# $content =~ s< {1,7}\t> <\t>;
- $data{$what}->{$tag} .= $content;
}
+ $data{$what}->{$tag} .= $content;
+
next;
}
if (m/^\s*(.*)/) {
--
2.26.2
Re: [PATCH v2] Documentation: Chinese translation of Documentation/arm64/perf.rst
Reviewed-by: Alex Shi 在 2020/10/30 下午12:05, Bailu Lin 写道: > This is a Chinese translated version of > Documentation/arm64/perf.rst > > Signed-off-by: Bailu Lin > ---
Re: [PATCH v7 08/12] ARM: dts: imx: Fix schema warnings for pwm-leds
On Mon, Oct 05, 2020 at 10:34:47PM +0200, Alexander Dahl wrote: > The node names for devices using the pwm-leds driver follow a certain > naming scheme (now). Parent node name is not enforced, but recommended > by DT project. > > DTC arch/arm/boot/dts/imx53-ppd.dt.yaml > CHECK arch/arm/boot/dts/imx53-ppd.dt.yaml > /home/alex/build/linux/arch/arm/boot/dts/imx53-ppd.dt.yaml: leds-brightness: > 'alarm-brightness' does not match any of the regexes: '^led(-[0-9a-f]+)?$', > 'pinctrl-[0-9]+' > From schema: > /home/alex/src/linux/leds/Documentation/devicetree/bindings/leds/leds-pwm.yaml > DTC arch/arm/boot/dts/imx6dl-cubox-i.dt.yaml > CHECK arch/arm/boot/dts/imx6dl-cubox-i.dt.yaml > /home/alex/build/linux/arch/arm/boot/dts/imx6dl-cubox-i.dt.yaml: pwmleds: > 'front' does not match any of the regexes: '^led(-[0-9a-f]+)?$', > 'pinctrl-[0-9]+' > From schema: > /home/alex/src/linux/leds/Documentation/devicetree/bindings/leds/leds-pwm.yaml > DTC arch/arm/boot/dts/imx6dl-cubox-i-emmc-som-v15.dt.yaml > CHECK arch/arm/boot/dts/imx6dl-cubox-i-emmc-som-v15.dt.yaml > /home/alex/build/linux/arch/arm/boot/dts/imx6dl-cubox-i-emmc-som-v15.dt.yaml: > pwmleds: 'front' does not match any of the regexes: '^led(-[0-9a-f]+)?$', > 'pinctrl-[0-9]+' > From schema: > /home/alex/src/linux/leds/Documentation/devicetree/bindings/leds/leds-pwm.yaml > DTC arch/arm/boot/dts/imx6dl-cubox-i-som-v15.dt.yaml > CHECK arch/arm/boot/dts/imx6dl-cubox-i-som-v15.dt.yaml > /home/alex/build/linux/arch/arm/boot/dts/imx6dl-cubox-i-som-v15.dt.yaml: > pwmleds: 'front' does not match any of the regexes: '^led(-[0-9a-f]+)?$', > 'pinctrl-[0-9]+' > From schema: > /home/alex/src/linux/leds/Documentation/devicetree/bindings/leds/leds-pwm.yaml > DTC arch/arm/boot/dts/imx6sx-softing-vining-2000.dt.yaml > CHECK arch/arm/boot/dts/imx6sx-softing-vining-2000.dt.yaml > /home/alex/build/linux/arch/arm/boot/dts/imx6sx-softing-vining-2000.dt.yaml: > pwmleds: 'blue', 'green', 'red' do not match any of the regexes: > '^led(-[0-9a-f]+)?$', 'pinctrl-[0-9]+' > From schema: > /home/alex/src/linux/leds/Documentation/devicetree/bindings/leds/leds-pwm.yaml > > Signed-off-by: Alexander Dahl Applied, thanks.
[rcu] 44bad5b3cc: dmesg.INFO:rcu_preempt_detected_stalls_on_CPUs/tasks
Greeting,
FYI, we noticed the following commit (built with gcc-9):
commit: 44bad5b3cca2d452d17ef82841b20b42a2cf11a0 ("rcu: Do full report for
.need_qs for strict GPs")
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master
in testcase: trinity
version: trinity-i386-4d2343bd-1_20200320
with following parameters:
runtime: 300s
test-description: Trinity is a linux system call fuzz tester.
test-url: http://codemonkey.org.uk/projects/trinity/
on test machine: qemu-system-i386 -enable-kvm -cpu SandyBridge -smp 2 -m 8G
caused below changes (please refer to attached dmesg/kmsg for entire
log/backtrace):
+--+++
| | f19920e412 | 44bad5b3cc |
+--+++
| boot_successes | 23 | 16 |
| boot_failures| 21 | 48 |
| BUG:kernel_hang_in_test_stage| 21 | 47 |
| INFO:rcu_preempt_self-detected_stall_on_CPU | 4 ||
| EIP:_raw_spin_unlock_irq | 5 | 25 |
| EIP:___might_sleep | 1 ||
| EIP:preempt_schedule_common | 4 | 2 |
| EIP:preempt_schedule_notrace | 4 ||
| EIP:__put_user_4 | 1 ||
| EIP:schedule | 9 | 40 |
| INFO:rcu_preempt_detected_stalls_on_CPUs/tasks | 8 | 40 |
| WARNING:at_net/sched/sch_generic.c:#dev_watchdog | 2 | 1 |
| EIP:dev_watchdog | 2 | 1 |
+--+++
If you fix the issue, kindly add following tag
Reported-by: kernel test robot
[ 311.442723] rcu: INFO: rcu_preempt detected stalls on CPUs/tasks:
[ 311.445504] (detected by 1, t=12 jiffies, g=83721, q=12)
[ 311.446491] rcu: All QSes seen, last rcu_preempt kthread activity 12
(10023--89979), jiffies_till_next_fqs=3, root ->qsmask 0x0
[ 311.448502] rcu: rcu_preempt kthread starved for 12 jiffies! g83721 f0x2
RCU_GP_WAIT_FQS(5) ->state=0x0 ->cpu=1
[ 311.450260] rcu: Unless rcu_preempt kthread gets sufficient CPU time,
OOM is now expected behavior.
[ 311.451793] rcu: RCU grace-period kthread stack dump:
[ 311.452650] task:rcu_preempt state:R running task stack:0 pid:
10 ppid: 2 flags:0x4008
[ 311.454190] Call Trace:
[ 311.454569] sched_show_task+0x125/0x137
[ 311.455208] rcu_check_gp_kthread_starvation+0xe4/0xf6
[ 311.456058] rcu_sched_clock_irq+0x7c3/0x89a
[ 311.456793] ? account_system_time+0x68/0x71
[ 311.457543] update_process_times+0x24/0x4f
[ 311.458273] tick_sched_handle+0x55/0x63
[ 311.458959] tick_sched_timer+0x3b/0x79
[ 311.459634] ? tick_sched_do_timer+0x44/0x44
[ 311.460353] __hrtimer_run_queues+0x13a/0x1fe
[ 311.461130] ? tick_sched_do_timer+0x44/0x44
[ 311.461861] hrtimer_interrupt+0xb0/0x1bc
[ 311.462575] ? sysvec_call_function_single+0x2c/0x2c
[ 311.463423] __sysvec_apic_timer_interrupt+0xc3/0x13b
[ 311.464306] sysvec_apic_timer_interrupt+0x1b/0x2e
[ 311.465097] handle_exception+0x143/0x143
[ 311.465747] EIP: _raw_spin_unlock_irq+0x25/0x2f
[ 311.466519] Code: 9e ff 5b 5d c3 66 66 66 66 90 55 89 e5 53 89 c3 83 c0 10
8b 55 04 e8 e5 80 a2 ff 89 d8 e8 1e b4 a2 ff fb 64 ff 0d f4 06 c8 41 <75> 05 e8
fe 77 98 ff 5b 5d c3 66 66 66 66 90 55 89 e5 56 89 d6 53
[ 311.469547] EAX: 0001 EBX: f5c0 ECX: EDX: f4eab840
[ 311.470573] ESI: EDI: f4eab840 EBP: f4eb5df8 ESP: f4eb5df4
[ 311.471709] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 EFLAGS: 0202
[ 311.472930] ? sysvec_call_function_single+0x2c/0x2c
[ 311.473771] ? _raw_spin_unlock_irq+0x25/0x2f
[ 311.474512] finish_task_switch+0x151/0x1dd
[ 311.475244] ? finish_task_switch+0x129/0x1dd
[ 311.476000] __schedule+0x4a2/0x4df
[ 311.476630] ? sysvec_call_function_single+0x2c/0x2c
[ 311.477479] preempt_schedule_irq+0x45/0x56
[ 311.478204] irqentry_exit_cond_resched+0x37/0x3a
[ 311.479018] irqentry_exit+0x33/0x42
[ 311.479649] sysvec_apic_timer_interrupt+0x2a/0x2e
[ 311.480520] handle_exception+0x143/0x143
[ 311.481187] EIP: schedule+0x8c/0xb2
[ 311.481752] Code: 39 d1 74 0a ba 01 00 00 00 e8 e7 de c8 ff 64 8b 35 fc 06
c8 41 64 ff 05 f4 06 c8 41 31 c0 e8 9c fa ff ff 64 ff 0d f4 06 c8 41 <8b> 06 a8
08 75 e5 8b 43 14 a9 20 00 00 20 74 12 a8 20 89 d8 74 07
[ 311.484809] EAX: EBX: f4eab840 ECX: EDX: f4eab840
[ 311.485882] ESI: f4eab840 EDI: 0003 EBP: f4eb5ef8 ESP: f4eb5ef0
[ 311.486967] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 EFLAGS: 0246
[ 311
Re: [PATCH v2 1/2] bpf: don't rely on GCC __attribute__((optimize)) to disable GCSE
On Fri, 30 Oct 2020 at 04:22, Alexei Starovoitov wrote: > > On Thu, Oct 29, 2020 at 05:28:11PM -0700, Nick Desaulniers wrote: > > > > We already know that -fno-asynchronous-unwind-tables get dropped, > > hence this patch. > > On arm64 only. Not on x86 > > > And we know -fomit-frame-pointer or > > -fno-omit-frame-pointer I guess gets dropped, hence your ask. > > yep. that one is bugged. > > > We might not know the full extent which other flags get dropped with the > > optimize attribute, but I'd argue that my list above can all result in > > pretty bad bugs when accidentally omitted (ok, maybe not -fshort-wchar > > or -fmacro-prefix-map, idk what those do) or when mixed with code that > > true. > Few month back I've checked that strict-aliasing and no-common flags > from your list are not dropped by this attr in gcc [6789]. > I've also checked that no-red-zone and model=kernel preserved as well. > > > has different values those flags control. Searching GCC's bug tracker > > for `__attribute__((optimize` turns up plenty of reports to make me > > think this attribute maybe doesn't work the way folks suspect or > > intend: > > https://gcc.gnu.org/bugzilla/buglist.cgi?quicksearch=__attribute__%28%28optimize&list_id=283390. > > There is a risk. > Is it a footgun? Sure. > Yet. gcc testsuite is using __attribute__((optimize)). > And some of these tests were added _after_ offical gcc doc said that this > attribute is broken. > imo it's like 'beware of the dog' sign. > > > There's plenty of folks arguing against the use of the optimize > > attribute in favor of the command line flag. I urge you to please > > reconsider the request. > > ok. Applied this first patch to bpf tree and will get it to Linus soon. > Second patch that is splitting interpreter out because of this mess > is dropped. The effect of gcse on performance is questionable. > iirc some interpreters used to do -fno-gcse to gain performance. That is absolutely fine. I only included the second patch to address Daniel's concern that -fno-gcse could affect unrelated code living in the same source file as __bpf_prog_run(), but if you don't care about that, nor will I.
Re: linux-next: failure while fetching the pinctrl-samsung-fixes tree
On Thu, 29 Oct 2020 at 22:10, Stephen Rothwell wrote: > > Hi all, > > Fetching the pinctrl-samsung-fixes tree produces this error: > > fatal: couldn't find remote ref refs/heads/pinctrl-fixes That's my fault - I wanted to have unified naming across by repositories. Could you start fetching branch "fixes" instead? Best Regards. Krzysztof
Re: linux-next: build failure after merge of the drm-misc tree
Am 30.10.20 um 01:07 schrieb Stephen Rothwell:
Hi all,
After merging the drm-misc tree, today's linux-next build (x86_64
allmodconfig) failed like this:
drivers/gpu/drm/nouveau/nouveau_ttm.c: In function 'nouveau_ttm_init':
drivers/gpu/drm/nouveau/nouveau_ttm.c:320:19: error: implicit declaration of
function 'swiotlb_nr_tbl' [-Werror=implicit-function-declaration]
320 | need_swiotlb = !!swiotlb_nr_tbl();
| ^~
Mhm, thanks for the note. Looks like there is some merge conflict to me.
In my tree there is an "#if IS_ENABLED(CONFIG_SWIOTLB) &&
IS_ENABLED(CONFIG_X86)" around that line making sure the function is
available.
Going to take a look later today.
Christian.
Caused by commit
ee5d2a8e549e ("drm/ttm: wire up the new pool as default one v2")
I have used the drm-misc tree from next-20201029 for today.
Re: [PATCH v2] clk: renesas: r8a774c0: Add RPC clocks
Hi Prabhakar,
On Thu, Oct 29, 2020 at 3:28 PM Geert Uytterhoeven wrote:
> On Thu, Oct 29, 2020 at 11:55 AM Lad Prabhakar
> wrote:
> > Describe the RPCSRC internal clock and the RPC[D2] clocks derived from it,
> > as well as the RPC-IF module clock, in the RZ/G2E (R8A774C0) CPG/MSSR
> > driver.
> > + if (e3_rpcsrc_parent) {
> > + parent = clks[core->parent >> 16];
> > + if (IS_ERR(parent))
> > + return ERR_CAST(parent);
> > + }
> > +
> > + return clk_register_divider_table(NULL, core->name,
> > + __clk_get_name(parent), 0,
> > + base + CPG_RPCCKCR, 3, 2,
> > 0,
> > + e3_rpcsrc_parent ?
> > +
> > cpg_rpcsrc_e3_pll1_div_table :
> > +
> > cpg_rpcsrc_e3_pll0_div_table,
> > + &cpg_lock);
> > +
>
> So you want to keep the parent clock selection fixed, but still allow
> the system to change the divider?
> Why not support changing the parent too, by modeling this as a composite
> clock consisting of a mux and a divider?
To clarify: basically you have two options here:
1. Model this clock as a non-mutable clock, based on the register settings
at the time the kernel boots. I.e. register it as a fixed-divider clock.
This is how we handle the PLLx clocks.
2. Model this clock as a fully-programmable clock. I.e. implement both
dynamic parent selection and dynamic divider selection.
You have picked something in between ;-)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH] arm64: dts: imx8mm-beacon-som: Fix Choppy BT audio
On Wed, Oct 07, 2020 at 08:02:37AM -0500, Adam Ford wrote:
> When streaming bluetooth audio, the sound is choppy due to the
> fact that the default baud rate of the HCI interface is too slow
> to handle 16-bit stereo at 48KHz.
>
> The Bluetooth chip is capable of up to 4M baud on the serial port,
> so this patch sets the max-speed to 400 in order to properly
> stream audio over the Bluetooth.
>
> Fixes: 593816fa2f35 ("arm64: dts: imx: Add Beacon i.MX8m-Mini development
> kit")
>
> Signed-off-by: Adam Ford
Applied, thanks.
Re: [Outreachy kernel] [PATCH] drm/amdgpu: use DEFINE_DEBUGFS_ATTRIBUTE with debugfs_create_file_unsafe()
On Fri, Oct 30, 2020 at 08:11:20AM +0100, Greg KH wrote: > On Fri, Oct 30, 2020 at 08:52:45AM +0530, Deepak R Varma wrote: > > Using DEFINE_DEBUGFS_ATTRIBUTE macro with debugfs_create_file_unsafe() > > function in place of the debugfs_create_file() function will make the > > file operation struct "reset" aware of the file's lifetime. Additional > > details here: https://lists.archive.carbon60.com/linux/kernel/2369498 > > > > Issue reported by Coccinelle script: > > scripts/coccinelle/api/debugfs/debugfs_simple_attr.cocci > > > > Signed-off-by: Deepak R Varma > > --- > > Please Note: This is a Outreachy project task patch. > > > > drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 20 ++-- > > 1 file changed, 10 insertions(+), 10 deletions(-) > > > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c > > b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c > > index 2d125b8b15ee..f076b1ba7319 100644 > > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c > > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c > > @@ -1551,29 +1551,29 @@ static int amdgpu_debugfs_sclk_set(void *data, u64 > > val) > > return 0; > > } > > > > -DEFINE_SIMPLE_ATTRIBUTE(fops_ib_preempt, NULL, > > - amdgpu_debugfs_ib_preempt, "%llu\n"); > > +DEFINE_DEBUGFS_ATTRIBUTE(fops_ib_preempt, NULL, > > +amdgpu_debugfs_ib_preempt, "%llu\n"); > > Are you sure this is ok? Do these devices need this additional > "protection"? Do they have the problem that these macros were written > for? > > Same for the other patches you just submitted here, I think you need to > somehow "prove" that these changes are necessary, checkpatch isn't able > to determine this all the time. Hi Greg, Based on my understanding, the current function debugfs_create_file() adds an overhead of lifetime managing proxy for such fop structs. This should be applicable to these set of drivers as well. Hence I think this change will be useful. I will wait for comments from other experts for driver specific consideration / behavior. Thanks, drv > > thanks, > > greg k-h
[PATCH v2 0/2] Modify documentation and machine driver for SC7180 sound card
Note: - The patch is made by the collaboration of Ajye Huang Cheng-Yi Chiang Changes from v1 to v2: - Ducumentation: Modify the dimc-gpios property description and examples. - Machine driver: - Remove "qcom,sc7180-sndcard-rt5682-m98357-2mic" compatible - See gpio property and use anadditional control. Thanks for the review! Ajye Huang (2): ASoC: google: dt-bindings: modify machine bindings for two MICs case ASoC: qcom: sc7180: Modify machine driver for 2mic .../bindings/sound/google,sc7180-trogdor.yaml | 58 ++ sound/soc/qcom/sc7180.c | 59 +++ 2 files changed, 117 insertions(+) -- 2.25.1
[PATCH v2 1/2] ASoC: google: dt-bindings: modify machine bindings for two MICs case
Add a property "dmic-gpios" for switching between two MICs.
Signed-off-by: Ajye Huang
---
.../bindings/sound/google,sc7180-trogdor.yaml | 58 +++
1 file changed, 58 insertions(+)
diff --git a/Documentation/devicetree/bindings/sound/google,sc7180-trogdor.yaml
b/Documentation/devicetree/bindings/sound/google,sc7180-trogdor.yaml
index efc34689d6b5..9e0505467e57 100644
--- a/Documentation/devicetree/bindings/sound/google,sc7180-trogdor.yaml
+++ b/Documentation/devicetree/bindings/sound/google,sc7180-trogdor.yaml
@@ -34,6 +34,9 @@ properties:
"#size-cells":
const: 0
+ dmic-gpios:
+description: GPIO for switching between DMICs
+
patternProperties:
"^dai-link(@[0-9])?$":
description:
@@ -81,6 +84,7 @@ additionalProperties: false
examples:
- |
+//Example 1
sound {
compatible = "google,sc7180-trogdor";
model = "sc7180-rt5682-max98357a-1mic";
@@ -128,3 +132,57 @@ examples:
};
};
};
+
+ - |
+//Example 2 (2mic case)
+sound {
+compatible = "google,sc7180-trogdor";
+model = "sc7180-rt5682-max98357a-2mic";
+
+audio-routing =
+"Headphone Jack", "HPOL",
+"Headphone Jack", "HPOR";
+
+#address-cells = <1>;
+#size-cells = <0>;
+
+dmic-gpios = <&tlmm 86 0>;
+
+dai-link@0 {
+link-name = "MultiMedia0";
+reg = <0>;
+cpu {
+sound-dai = <&lpass_cpu 0>;
+};
+
+codec {
+sound-dai = <&alc5682 0>;
+};
+};
+
+dai-link@1 {
+link-name = "MultiMedia1";
+reg = <1>;
+cpu {
+sound-dai = <&lpass_cpu 1>;
+};
+
+codec {
+sound-dai = <&max98357a>;
+};
+};
+
+dai-link@2 {
+link-name = "MultiMedia2";
+reg = <2>;
+cpu {
+sound-dai = <&lpass_hdmi 0>;
+};
+
+codec {
+sound-dai = <&msm_dp>;
+};
+};
+};
+
+...
--
2.25.1
Re: [RFC PATCH v2] selinux: Fix kmemleak after disabling selinux runtime
Hi, On 2020/10/29 0:29, Casey Schaufler wrote: > On 10/27/2020 7:06 PM, Chen Jun wrote: >> From: Chen Jun >> >> Kmemleak will report a problem after using >> "echo 1 > /sys/fs/selinux/disable" to disable selinux on runtime. > > Runtime disable of SELinux has been deprecated. It would be > wasteful to make these changes in support of a facility that > is going away. > But this sysfs file will still be present and workable on LTS kernel versions, so is the proposed fixe OK for these LTS kernel versions ? Regards, Tao >> >> kmemleak report： >> unreferenced object 0x901281c208a0 (size 96): >> comm "swapper/0", pid 1, jiffies 4294668265 (age 692.799s) >> hex dump (first 32 bytes): >> 00 40 c8 81 12 90 ff ff 03 00 00 00 05 00 00 00 .@.. >> 03 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >> backtrace: >> [<14622ef8>] selinux_sb_alloc_security+0x1b/0xa0 >> [<044914e1>] security_sb_alloc+0x1d/0x30 >> [<9f9d5ffd>] alloc_super+0xa7/0x310 >> [<3c5f0b5b>] sget_fc+0xca/0x230 >> [<367a9996>] vfs_get_super+0x37/0x110 >> [<1c47e818>] vfs_get_tree+0x20/0xc0 >> [] fc_mount+0x9/0x30 >> [<708a102f>] vfs_kern_mount.part.36+0x6a/0x80 >> [<5db542fe>] kern_mount+0x1b/0x30 >> [<51919f9f>] init_sel_fs+0x8b/0x119 >> [<0f328fe0>] do_one_initcall+0x3f/0x1d0 >> [<8a6ceb81>] kernel_init_freeable+0x1b4/0x1f2 >> [<3a425dcd>] kernel_init+0x5/0x110 >> [<4e8d6c9d>] ret_from_fork+0x22/0x30 >> >> "echo 1 > /sys/fs/selinux/disable" will delete the hooks. >> Any memory alloced by calling HOOKFUNCTION (like >> call_int_hook(sb_alloc_security, 0, sb)) >> has no chance to be freed after deleting hooks. >> >> Add a flag to mark a hook not be delete when deleting hooks. >> >> Signed-off-by: Chen Jun >> --- >> include/linux/lsm_hooks.h | 6 +- >> security/selinux/hooks.c | 20 ++-- >> 2 files changed, 15 insertions(+), 11 deletions(-) >> >> diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h >> index c503f7ab8afb..85de731b0c74 100644 >> --- a/include/linux/lsm_hooks.h >> +++ b/include/linux/lsm_hooks.h >> @@ -1554,6 +1554,7 @@ struct security_hook_list { >> struct hlist_head *head; >> union security_list_options hook; >> char*lsm; >> +boolno_del; >> } __randomize_layout; >> >> /* >> @@ -1582,6 +1583,8 @@ struct lsm_blob_sizes { >> */ >> #define LSM_HOOK_INIT(HEAD, HOOK) \ >> { .head = &security_hook_heads.HEAD, .hook = { .HEAD = HOOK } } >> +#define LSM_HOOK_INIT_NO_DEL(HEAD, HOOK) \ >> +{ .head = &security_hook_heads.HEAD, .hook = { .HEAD = HOOK }, .no_del >> = 1 } >> >> extern struct security_hook_heads security_hook_heads; >> extern char *lsm_names; >> @@ -1638,7 +1641,8 @@ static inline void security_delete_hooks(struct >> security_hook_list *hooks, >> int i; >> >> for (i = 0; i < count; i++) >> -hlist_del_rcu(&hooks[i].list); >> +if (!hooks[i].no_del) >> +hlist_del_rcu(&hooks[i].list); >> } >> #endif /* CONFIG_SECURITY_SELINUX_DISABLE */ >> >> diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c >> index 6b1826fc3658..daff084fd1c7 100644 >> --- a/security/selinux/hooks.c >> +++ b/security/selinux/hooks.c >> @@ -6974,8 +6974,8 @@ static struct security_hook_list selinux_hooks[] >> __lsm_ro_after_init = { >> LSM_HOOK_INIT(bprm_committing_creds, selinux_bprm_committing_creds), >> LSM_HOOK_INIT(bprm_committed_creds, selinux_bprm_committed_creds), >> >> -LSM_HOOK_INIT(sb_free_security, selinux_sb_free_security), >> -LSM_HOOK_INIT(sb_free_mnt_opts, selinux_free_mnt_opts), >> +LSM_HOOK_INIT_NO_DEL(sb_free_security, selinux_sb_free_security), >> +LSM_HOOK_INIT_NO_DEL(sb_free_mnt_opts, selinux_free_mnt_opts), >> LSM_HOOK_INIT(sb_remount, selinux_sb_remount), >> LSM_HOOK_INIT(sb_kern_mount, selinux_sb_kern_mount), >> LSM_HOOK_INIT(sb_show_options, selinux_sb_show_options), >> @@ -7081,7 +7081,7 @@ static struct security_hook_list selinux_hooks[] >> __lsm_ro_after_init = { >> >> LSM_HOOK_INIT(ismaclabel, selinux_ismaclabel), >> LSM_HOOK_INIT(secctx_to_secid, selinux_secctx_to_secid), >> -LSM_HOOK_INIT(release_secctx, selinux_release_secctx), >> +LSM_HOOK_INIT_NO_DEL(release_secctx, selinux_release_secctx), >> LSM_HOOK_INIT(inode_invalidate_secctx, selinux_inode_invalidate_secctx), >> LSM_HOOK_INIT(inode_notifysecctx, selinux_inode_notifysecctx), >> LSM_HOOK_INIT(inode_setsecctx, selinux_inode_setsecctx), >> @@ -7107,7 +7107,7 @@ static struct security_hook_list selinux_hooks[] >> __lsm_ro_after_init = { >> LSM_HOOK_INIT(socket_getpeersec_stream, >> selinux_socket_getpeersec_stream), >> LSM_HOOK_
[PATCH v2 2/2] ASoC: qcom: sc7180: Modify machine driver for 2mic
In addition, having mixer control to switch between DMICs by
using "dmic-gpios" property.
Refer to this one as an example,
commit b7a742cff3f6 ("ASoC: AMD: Use mixer control to switch between DMICs")
Signed-off-by: Ajye Huang
---
sound/soc/qcom/sc7180.c | 59 +
1 file changed, 59 insertions(+)
diff --git a/sound/soc/qcom/sc7180.c b/sound/soc/qcom/sc7180.c
index b391f64c3a80..e9366bb5f3c2 100644
--- a/sound/soc/qcom/sc7180.c
+++ b/sound/soc/qcom/sc7180.c
@@ -5,6 +5,8 @@
// sc7180.c -- ALSA SoC Machine driver for SC7180
#include
+#include
+#include
#include
#include
#include
@@ -23,6 +25,9 @@
#define DRIVER_NAME "SC7180"
+static struct gpio_desc *dmic_sel;
+static int dmic_switch;
+
struct sc7180_snd_data {
struct snd_soc_card card;
u32 pri_mi2s_clk_count;
@@ -169,6 +174,23 @@ static int sc7180_snd_startup(struct snd_pcm_substream
*substream)
return 0;
}
+static int dmic_get(struct snd_kcontrol *kcontrol,
+ struct snd_ctl_elem_value *ucontrol)
+{
+ ucontrol->value.integer.value[0] = dmic_switch;
+ return 0;
+}
+
+static int dmic_set(struct snd_kcontrol *kcontrol,
+ struct snd_ctl_elem_value *ucontrol)
+{
+ if (dmic_sel) {
+ dmic_switch = ucontrol->value.integer.value[0];
+ gpiod_set_value(dmic_sel, dmic_switch);
+ }
+ return 0;
+}
+
static void sc7180_snd_shutdown(struct snd_pcm_substream *substream)
{
struct snd_soc_pcm_runtime *rtd = substream->private_data;
@@ -206,6 +228,30 @@ static const struct snd_soc_dapm_widget
sc7180_snd_widgets[] = {
SND_SOC_DAPM_MIC("Headset Mic", NULL),
};
+static const char * const dmic_mux_text[] = {
+ "Front Mic",
+ "Rear Mic",
+};
+
+static SOC_ENUM_SINGLE_DECL(sc7180_dmic_enum,
+ SND_SOC_NOPM, 0, dmic_mux_text);
+
+static const struct snd_kcontrol_new sc7180_dmic_mux_control =
+ SOC_DAPM_ENUM_EXT("DMIC Select Mux", sc7180_dmic_enum,
+ dmic_get, dmic_set);
+
+static const struct snd_soc_dapm_widget sc7180_snd_dual_mic_widgets[] = {
+ SND_SOC_DAPM_HP("Headphone Jack", NULL),
+ SND_SOC_DAPM_MIC("Headset Mic", NULL),
+ SND_SOC_DAPM_MIC("DMIC", NULL),
+ SND_SOC_DAPM_MUX("Dmic Mux", SND_SOC_NOPM, 0, 0,
&sc7180_dmic_mux_control),
+};
+
+static const struct snd_soc_dapm_route sc7180_snd_dual_mic_audio_route[] = {
+ {"Dmic Mux", "Front Mic", "DMIC"},
+ {"Dmic Mux", "Rear Mic", "DMIC"},
+};
+
static void sc7180_add_ops(struct snd_soc_card *card)
{
struct snd_soc_dai_link *link;
@@ -238,6 +284,19 @@ static int sc7180_snd_platform_probe(struct
platform_device *pdev)
card->dapm_widgets = sc7180_snd_widgets;
card->num_dapm_widgets = ARRAY_SIZE(sc7180_snd_widgets);
+ if (of_property_read_bool(dev->of_node, "dmic-gpios")) {
+ card->dapm_widgets = sc7180_snd_dual_mic_widgets,
+ card->num_dapm_widgets =
ARRAY_SIZE(sc7180_snd_dual_mic_widgets),
+ card->dapm_routes = sc7180_snd_dual_mic_audio_route,
+ card->num_dapm_routes =
ARRAY_SIZE(sc7180_snd_dual_mic_audio_route),
+ dmic_sel = devm_gpiod_get(&pdev->dev, "dmic", GPIOD_OUT_LOW);
+ if (IS_ERR(dmic_sel)) {
+ dev_err(&pdev->dev, "DMIC gpio failed err=%d\n",
+ PTR_ERR(dmic_sel));
+ return PTR_ERR(dmic_sel);
+ }
+ }
+
ret = qcom_snd_parse_of(card);
if (ret)
return ret;
--
2.25.1
Re: [PATCH 2/3] mwifiex: add allow_ps_mode module parameter
On Wed, 2020-10-28 at 15:04 -0700, Brian Norris wrote:
> On Wed, Oct 28, 2020 at 2:56 PM Tsuchiya Yuto wrote:
> >
> > To make the ps_mode (power_save) control easier, this commit adds a new
> > module parameter allow_ps_mode and set it false (disallowed) by default.
>
> This sounds like a bad idea, as it breaks all the existing users who
> expect this feature to be allowed. Seems like you should flip the
> defaults. Without some better justification, NACK.
Thanks for the review! I wanted to open a discussion widely and wanted
to ask from the upstream developers the direction of how this stability
issue should be resolved.
I added the link to the Bugzilla in the cover-letter (that should have
arrived on the mailing list now), but I should have added this to every
commit as well:
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=109681
This stability issue exists for a long time. I also submitted there the
required kernel log and device_dump more than three months ago. However,
unfortunately, it's not fixed yet. So, I have to send a series like this.
If we know that the power_save feature is broken (on some devices), I
think it should be fixed in either firmware or driver for the affected
devices. It makes no sense to keep enabling the broken features by
default.
Because userspace tools sometimes try to enable power_save anyway
regardless of default driver settings (expecting it's not broken, but
in fact it's broken), the module parameter like this is required in
addition to the first patch of this series. The commit 8298383c2cd5
("ath9k: Do not support PowerSave by default") also does the same thing
for this purpose.
On the other hand, I agree that I don't want to break the existing users.
As you mentioned in the reply to the first patch, I can set the default
value of this parameter depending on the chip id (88W8897) or DMI matching.
> Also, I can't find the other 2 patches in this alleged series. Maybe
> they're still making it through the mailing lists and archives.
Yes, there seems to be a problem with the mailing list at the time.
All the other patches I sent have arrived by now.
> Brian
>
> > When this parameter is set to false, changing the power_save mode will
> > be disallowed like the following:
> >
> > $ sudo iw dev mlan0 set power_save on
> > command failed: Operation not permitted (-1)
> >
> > Signed-off-by: Tsuchiya Yuto
Re: [PATCHv2 2/4] coresight: tmc-etf: Fix NULL ptr dereference in tmc_enable_etf_sink_perf()
Hello guys, On 2020-10-24 02:07, Mathieu Poirier wrote: On Fri, Oct 23, 2020 at 03:44:16PM +0200, Peter Zijlstra wrote: On Fri, Oct 23, 2020 at 02:29:54PM +0100, Suzuki Poulose wrote: > On 10/23/20 2:16 PM, Peter Zijlstra wrote: > > On Fri, Oct 23, 2020 at 01:56:47PM +0100, Suzuki Poulose wrote: > > > That way another session could use the same sink if it is free. i.e > > > > > > perf record -e cs_etm/@sink0/u --per-thread app1 > > > > > > and > > > > > > perf record -e cs_etm/@sink0/u --per-thread app2 > > > > > > both can work as long as the sink is not used by the other session. > > > > Like said above, if sink is shared between CPUs, that's going to be a > > trainwreck :/ Why do you want that? > > That ship has sailed. That is how the current generation of systems are, > unfortunately. But as I said, this is changing and there are guidelines > in place to avoid these kind of topologies. With the future > technologies, this will be completely gone. I understand that the hardware is like that, but why do you want to support this insanity in software? If you only allow a single sink user (group) at the same time, your problem goes away. Simply disallow the above scenario, do not allow concurrent sink users if sinks are shared like this. Have the perf-record of app2 above fail because the sink is in-user already. I agree with you that --per-thread scenarios are easy to deal with, but to support cpu-wide scenarios events must share a sink (because there is one event per CPU). CPU-wide support can't be removed because it has been around for close to a couple of years and heavily used. I also think using the pid of the process that created the events, i.e perf, is a good idea. We just need to agree on how to gain access to it. In Sai's patch you objected to the following: + struct task_struct *task = READ_ONCE(event->owner); + + if (!task || is_kernel_event(event)) Would it be better to use task_nr_pid(current) instead of event->owner? The end result will be exactly the same. There is also no need to check the validity of @current since it is a user process. We have devices deployed where these crashes are seen consistently, so for some immediate relief, could we atleast get some fix in this cycle without major design overhaul which would likely take more time. Perhaps my first patch [1] without any check for owner or I can post a new version as Suzuki suggested [2] dropping the export of is_kernel_event(). Then we can always work on top of it based on the conclusion of this discussion, we will atleast not have the systems crash in the meantime, thoughts? [1] https://lore.kernel.org/patchwork/patch/1318098/ [2] https://lore.kernel.org/lkml/fa6cdf34-88a0-1050-b9ea-556d0a943...@arm.com/ Thanks, Sai -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
Re: [Outreachy kernel] [PATCH] drm/amdgpu: use DEFINE_DEBUGFS_ATTRIBUTE with debugfs_create_file_unsafe()
Am 30.10.20 um 08:57 schrieb Deepak R Varma: On Fri, Oct 30, 2020 at 08:11:20AM +0100, Greg KH wrote: On Fri, Oct 30, 2020 at 08:52:45AM +0530, Deepak R Varma wrote: Using DEFINE_DEBUGFS_ATTRIBUTE macro with debugfs_create_file_unsafe() function in place of the debugfs_create_file() function will make the file operation struct "reset" aware of the file's lifetime. Additional details here: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.archive.carbon60.com%2Flinux%2Fkernel%2F2369498&data=04%7C01%7Cchristian.koenig%40amd.com%7Cddd7a6ac8164415a639708d87ca97004%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637396414464384011%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=o6GOHvMxNMuOPlC4nhDyURCHBLqfQZhYQq%2BiIMt3D3s%3D&reserved=0 Issue reported by Coccinelle script: scripts/coccinelle/api/debugfs/debugfs_simple_attr.cocci Signed-off-by: Deepak R Varma --- Please Note: This is a Outreachy project task patch. drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 20 ++-- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c index 2d125b8b15ee..f076b1ba7319 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c @@ -1551,29 +1551,29 @@ static int amdgpu_debugfs_sclk_set(void *data, u64 val) return 0; } -DEFINE_SIMPLE_ATTRIBUTE(fops_ib_preempt, NULL, - amdgpu_debugfs_ib_preempt, "%llu\n"); +DEFINE_DEBUGFS_ATTRIBUTE(fops_ib_preempt, NULL, +amdgpu_debugfs_ib_preempt, "%llu\n"); Are you sure this is ok? Do these devices need this additional "protection"? Do they have the problem that these macros were written for? Same for the other patches you just submitted here, I think you need to somehow "prove" that these changes are necessary, checkpatch isn't able to determine this all the time. Hi Greg, Based on my understanding, the current function debugfs_create_file() adds an overhead of lifetime managing proxy for such fop structs. This should be applicable to these set of drivers as well. Hence I think this change will be useful. Well since this is only created once per device instance I don't really care about this little overhead. But what exactly is debugfs doing or not doing here? Regards, Christian. I will wait for comments from other experts for driver specific consideration / behavior. Thanks, drv thanks, greg k-h
Re: [PATCH] arm64: dts: imx8mm-beacon-som: Configure supplies on secondary cpus
On Wed, Oct 07, 2020 at 09:04:57AM -0500, Adam Ford wrote: > Each cpu core should have a corresponding supply, but only cpu0 does. > This patch adds a supply for each of the secondary cpus. > > Signed-off-by: Adam Ford Applied, thanks.
Re: [PATCH 2/3] mwifiex: add allow_ps_mode module parameter
On Thu, 2020-10-29 at 13:04 -0400, Willem de Bruijn wrote:
> On Wed, Oct 28, 2020 at 9:13 PM Brian Norris wrote:
> >
> > On Wed, Oct 28, 2020 at 2:56 PM Tsuchiya Yuto wrote:
> > >
> > > To make the ps_mode (power_save) control easier, this commit adds a new
> > > module parameter allow_ps_mode and set it false (disallowed) by default.
>
> This sounds like some form of access control, not something that makes
> power control "easier"? What exactly is the use case.
Thanks for the review!
As I replied to Brian, userspace tools sometimes try to enable power_save
anyway regardless of default driver settings (expecting it's not broken,
but in fact it's broken), the module parameter like this is required.
So, the commit message is misleading. What will be "easier" is letting
userspace tools know power_save should be off, not the procedure of
toggling ps_mode state in the driver.
> Also, module params in networking devices are discouraged.
Even though it should be avoided, some upstream drivers provide a module
parameter like this to let users enable it if needed (since they disable
power_save by default because of stability on some devices) likw this
commit 0172b0292649 ("iwlagn: add power_save module parameter").
Re: [Outreachy kernel] [PATCH] drm/amdgpu: use DEFINE_DEBUGFS_ATTRIBUTE with debugfs_create_file_unsafe()
On Fri, Oct 30, 2020 at 01:27:16PM +0530, Deepak R Varma wrote: > On Fri, Oct 30, 2020 at 08:11:20AM +0100, Greg KH wrote: > > On Fri, Oct 30, 2020 at 08:52:45AM +0530, Deepak R Varma wrote: > > > Using DEFINE_DEBUGFS_ATTRIBUTE macro with debugfs_create_file_unsafe() > > > function in place of the debugfs_create_file() function will make the > > > file operation struct "reset" aware of the file's lifetime. Additional > > > details here: https://lists.archive.carbon60.com/linux/kernel/2369498 > > > > > > Issue reported by Coccinelle script: > > > scripts/coccinelle/api/debugfs/debugfs_simple_attr.cocci > > > > > > Signed-off-by: Deepak R Varma > > > --- > > > Please Note: This is a Outreachy project task patch. > > > > > > drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 20 ++-- > > > 1 file changed, 10 insertions(+), 10 deletions(-) > > > > > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c > > > b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c > > > index 2d125b8b15ee..f076b1ba7319 100644 > > > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c > > > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c > > > @@ -1551,29 +1551,29 @@ static int amdgpu_debugfs_sclk_set(void *data, > > > u64 val) > > > return 0; > > > } > > > > > > -DEFINE_SIMPLE_ATTRIBUTE(fops_ib_preempt, NULL, > > > - amdgpu_debugfs_ib_preempt, "%llu\n"); > > > +DEFINE_DEBUGFS_ATTRIBUTE(fops_ib_preempt, NULL, > > > + amdgpu_debugfs_ib_preempt, "%llu\n"); > > > > Are you sure this is ok? Do these devices need this additional > > "protection"? Do they have the problem that these macros were written > > for? > > > > Same for the other patches you just submitted here, I think you need to > > somehow "prove" that these changes are necessary, checkpatch isn't able > > to determine this all the time. > > Hi Greg, > Based on my understanding, the current function debugfs_create_file() > adds an overhead of lifetime managing proxy for such fop structs. This > should be applicable to these set of drivers as well. Hence I think this > change will be useful. Why do these drivers need these changes? Are these files dynamically removed from the system at random times? There is a reason we didn't just do a global search/replace for this in the kernel when the new functions were added, so I don't know why checkpatch is now saying it must be done. thanks, greg k-h
Re: [PATCH 1/1] debugfs: Add a helper to export atomic64_t values
On Fri, Oct 30, 2020 at 06:30:49PM +1100, Anand K. Mistry wrote:
> On Fri, 30 Oct 2020 at 18:20, Greg Kroah-Hartman
> wrote:
> >
> > On Fri, Oct 30, 2020 at 06:04:42PM +1100, Anand K Mistry wrote:
> > > This mirrors support for exporting atomic_t values.
> > >
> > > Signed-off-by: Anand K Mistry
> > >
> > > ---
> > >
> > > fs/debugfs/file.c | 37 +
> > > include/linux/debugfs.h | 6 ++
> > > 2 files changed, 43 insertions(+)
> > >
> > > diff --git a/fs/debugfs/file.c b/fs/debugfs/file.c
> > > index a768a09430c3..798bd3bdedec 100644
> > > --- a/fs/debugfs/file.c
> > > +++ b/fs/debugfs/file.c
> > > @@ -770,6 +770,43 @@ void debugfs_create_atomic_t(const char *name,
> > > umode_t mode,
> > > }
> > > EXPORT_SYMBOL_GPL(debugfs_create_atomic_t);
> > >
> > > +static int debugfs_atomic64_t_set(void *data, u64 val)
> > > +{
> > > + atomic64_set((atomic64_t *)data, val);
> > > + return 0;
> > > +}
> > > +static int debugfs_atomic64_t_get(void *data, u64 *val)
> > > +{
> > > + *val = atomic64_read((atomic64_t *)data);
> > > + return 0;
> > > +}
> > > +DEFINE_DEBUGFS_ATTRIBUTE(fops_atomic64_t, debugfs_atomic64_t_get,
> > > + debugfs_atomic64_t_set, "%lld\n");
> > > +DEFINE_DEBUGFS_ATTRIBUTE(fops_atomic64_t_ro, debugfs_atomic64_t_get,
> > > NULL,
> > > + "%lld\n");
> > > +DEFINE_DEBUGFS_ATTRIBUTE(fops_atomic64_t_wo, NULL,
> > > debugfs_atomic64_t_set,
> > > + "%lld\n");
> > > +
> > > +/**
> > > + * debugfs_create_atomic64_t - create a debugfs file that is used to
> > > read and
> > > + * write an atomic64_t value
> > > + * @name: a pointer to a string containing the name of the file to
> > > create.
> > > + * @mode: the permission that the file should have
> > > + * @parent: a pointer to the parent dentry for this file. This should
> > > be a
> > > + * directory dentry if set. If this parameter is %NULL, then
> > > the
> > > + * file will be created in the root of the debugfs filesystem.
> > > + * @value: a pointer to the variable that the file should read to and
> > > write
> > > + * from.
> > > + */
> > > +void debugfs_create_atomic64_t(const char *name, umode_t mode,
> > > +struct dentry *parent, atomic64_t *value)
> > > +{
> > > + debugfs_create_mode_unsafe(name, mode, parent, value,
> > > +&fops_atomic64_t, &fops_atomic64_t_ro,
> > > +&fops_atomic64_t_wo);
> > > +}
> > > +EXPORT_SYMBOL_GPL(debugfs_create_atomic64_t);
> > > +
> > > ssize_t debugfs_read_file_bool(struct file *file, char __user *user_buf,
> > > size_t count, loff_t *ppos)
> > > {
> > > diff --git a/include/linux/debugfs.h b/include/linux/debugfs.h
> > > index 851dd1f9a8a5..0fac84c53eab 100644
> > > --- a/include/linux/debugfs.h
> > > +++ b/include/linux/debugfs.h
> > > @@ -126,6 +126,8 @@ void debugfs_create_size_t(const char *name, umode_t
> > > mode,
> > > struct dentry *parent, size_t *value);
> > > void debugfs_create_atomic_t(const char *name, umode_t mode,
> > >struct dentry *parent, atomic_t *value);
> > > +void debugfs_create_atomic64_t(const char *name, umode_t mode,
> > > + struct dentry *parent, atomic64_t
> > > *value);
> > > struct dentry *debugfs_create_bool(const char *name, umode_t mode,
> > > struct dentry *parent, bool *value);
> > >
> > > @@ -291,6 +293,10 @@ static inline void debugfs_create_atomic_t(const
> > > char *name, umode_t mode,
> > > atomic_t *value)
> > > { }
> > >
> > > +static inline void debugfs_create_atomic64_t(const char *name, umode_t
> > > mode,
> > > + struct dentry *parent,
> > > atomic64_t *value)
> > > +{ }
> > > +
> > > static inline struct dentry *debugfs_create_bool(const char *name,
> > > umode_t mode,
> > >struct dentry *parent,
> > >bool *value)
> >
> > Looks good, but where is the user of this code? I can't add new apis
> > without a user.
>
> Fair enough. Right now, the user is just some local
> debugging/performance measuring which will never be upstreamed.
> Happy to let this drop.
Now dropped!
> > And are you _SURE_ you want to be using an atomic64_t in the first
> > place? We are starting to reduce the "raw" usage of atomic variables as
> > almost no one needs them, they should be using something else instead,
> > or just a u64 as atomics are not needed for simple statistics.
>
> I understand, and would generally never use atomics in real code. I
> used an atomic since I wanted accuracy (for some of the benchmarks I
> want to run) but can't use anything that blocks (spinlock/mutex) since
> the code is som
[PATCH 0/2] Designware I2C slave confusing IC_INTR_STOP_DET handle
When an I2C slave works, sometimes both IC_INTR_RX_FULL and IC_INTR_STOP_DET may be rising during an IRQ handle, especially when system is busy or too late to handle interrupts. If IC_INTR_RX_FULL is rising and the system doesn't handle immediately, IC_INTR_STOP_DET may be rising and the system has to handle these two events. For this there may be two problems: 1. IC_INTR_STOP_DET is rising after i2c_dw_read_clear_intrbits_slave() done: It seems invalidated because I2C_SLAVE_WRITE_REQUESTED is reported after the 1st I2C_SLAVE_WRITE_RECEIVED. $ i2cset -f -y 2 0x42 0x00 0x41; dmesg -c [0][clear_intrbits]0x1 STATUS SLAVE_ACTIVITY=0x1 : RAW_INTR_STAT=0x514 : INTR_STAT=0x4 [1][irq_handler ]0x1 STATUS SLAVE_ACTIVITY=0x1 : RAW_INTR_STAT=0x514 : INTR_STAT=0x4 I2C_SLAVE_WRITE_RECEIVED [0][clear_intrbits]0x1 STATUS SLAVE_ACTIVITY=0x1 : RAW_INTR_STAT=0x514 : INTR_STAT=0x4 [1][irq_handler ]0x1 STATUS SLAVE_ACTIVITY=0x0 : RAW_INTR_STAT=0x714 : INTR_STAT=0x204 I2C_SLAVE_WRITE_REQUESTED I2C_SLAVE_WRITE_RECEIVED [0][clear_intrbits]0x1 STATUS SLAVE_ACTIVITY=0x0 : RAW_INTR_STAT=0x710 : INTR_STAT=0x200 [1][irq_handler ]0x1 STATUS SLAVE_ACTIVITY=0x0 : RAW_INTR_STAT=0x510 : INTR_STAT=0x0 I2C_SLAVE_STOP [2][clear_intrbits]0x1 STATUS SLAVE_ACTIVITY=0x0 : RAW_INTR_STAT=0x510 : INTR_STAT=0x0 t1: ISR with the 1st IC_INTR_RX_FULL. t2: Clear listed IC_INTR bits by i2c_dw_read_clear_intrbits_slave(). t3: Enter i2c_dw_irq_handler_slave() and then report I2C_SLAVE_WRITE_RECEIVED due to 'if (stat & DW_IC_INTR_RX_FULL)' matched. t4: ISR with the 2nd IC_INTR_RX_FULL. t5: Clear listed IC_INTR bits by i2c_dw_read_clear_intrbits_slave() while IC_INTR_STOP_DET has not risen yet. t6: IC_INTR_STOP_DET is rising after entering i2c_dw_irq_handler_slave(). The driver reports I2C_SLAVE_WRITE_REQUESTED first due to 'if ((stat & DW_IC_INTR_RX_FULL) && (stat & DW_IC_INTR_STOP_DET))' matched and then reports I2C_SLAVE_WRITE_RECEIVED. t7: Reports I2C_SLAVE_STOP due to IC_INTR_STOP_DET not be cleared yet. 2. Both IC_INTR_STOP_DET and IC_INTR_RX_FULL are rising before i2c_dw_read_clear_intrbits_slave(): I2C_SLAVE_STOP never be reported because IC_INTR_STOP_DET was cleared by i2c_dw_read_clear_intrbits_slave(). $ i2cset -f -y 2 0x42 0x00 0x41; dmesg -c [0][clear_intrbits]0x1 STATUS SLAVE_ACTIVITY=0x1 : RAW_INTR_STAT=0x514 : INTR_STAT=0x4 [1][irq_handler ]0x1 STATUS SLAVE_ACTIVITY=0x1 : RAW_INTR_STAT=0x514 : INTR_STAT=0x4 I2C_SLAVE_WRITE_RECEIVED [0][clear_intrbits]0x1 STATUS SLAVE_ACTIVITY=0x0 : RAW_INTR_STAT=0x714 : INTR_STAT=0x204 [1][irq_handler ]0x1 STATUS SLAVE_ACTIVITY=0x0 : RAW_INTR_STAT=0x514 : INTR_STAT=0x4 I2C_SLAVE_WRITE_RECEIVED t1: ISR with the 1st IC_INTR_RX_FULL. t2: Clear listed IC_INTR bits by i2c_dw_read_clear_intrbits_slave(). t3: Enter i2c_dw_irq_handler_slave() and then report I2C_SLAVE_WRITE_RECEIVED due to 'if (stat & DW_IC_INTR_RX_FULL)' matched. t4: ISR with both IC_INTR_STOP_DET and the 2nd IC_INTR_RX_FULL. t5: Clear listed IC_INTR bits by i2c_dw_read_clear_intrbits_slave(). The current IC_INTR_STOP_DET was cleared by this i2c_dw_read_clear_intrbits_slave(). t6: Enter i2c_dw_irq_handler_slave() and then report i2c_slave_event(WRITE_RECEIVED) due to 'if (stat & DW_IC_INTR_RX_FULL)' matched. t7: I2C_SLAVE_STOP never be reported because IC_INTR_STOP_DET was cleared in t5. In order to resolve these problems, i2c_dw_read_clear_intrbits_slave() should be called only once in an ISR and take the returned stat to handle those occurred events. The ISR handling has to be adjusted to conform event reporting described in Documentation/i2c/slave-interface.rst. Michael Wu (2): i2c: designware: call i2c_dw_read_clear_intrbits_slave() once i2c: designware: slave should do WRITE_REQUESTED before WRITE_RECEIVED drivers/i2c/busses/i2c-designware-slave.c | 52 +-- 1 file changed, 19 insertions(+), 33 deletions(-) -- 2.17.1
[PATCH 1/2] i2c: designware: call i2c_dw_read_clear_intrbits_slave() once
If some bits were cleared by i2c_dw_read_clear_intrbits_slave() in
i2c_dw_isr_slave() and not handled immediately, those cleared bits would
not be shown again by later i2c_dw_read_clear_intrbits_slave(). They
therefore were forgotten to be handled.
i2c_dw_read_clear_intrbits_slave() should be called once in an ISR and take
its returned state for all later handlings.
Signed-off-by: Michael Wu
Acked-by: Jarkko Nikula
---
drivers/i2c/busses/i2c-designware-slave.c | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/drivers/i2c/busses/i2c-designware-slave.c
b/drivers/i2c/busses/i2c-designware-slave.c
index 44974b53a626..13de01a0f75f 100644
--- a/drivers/i2c/busses/i2c-designware-slave.c
+++ b/drivers/i2c/busses/i2c-designware-slave.c
@@ -159,7 +159,6 @@ static int i2c_dw_irq_handler_slave(struct dw_i2c_dev *dev)
u32 raw_stat, stat, enabled, tmp;
u8 val = 0, slave_activity;
- regmap_read(dev->map, DW_IC_INTR_STAT, &stat);
regmap_read(dev->map, DW_IC_ENABLE, &enabled);
regmap_read(dev->map, DW_IC_RAW_INTR_STAT, &raw_stat);
regmap_read(dev->map, DW_IC_STATUS, &tmp);
@@ -168,6 +167,7 @@ static int i2c_dw_irq_handler_slave(struct dw_i2c_dev *dev)
if (!enabled || !(raw_stat & ~DW_IC_INTR_ACTIVITY) || !dev->slave)
return 0;
+ stat = i2c_dw_read_clear_intrbits_slave(dev);
dev_dbg(dev->dev,
"%#x STATUS SLAVE_ACTIVITY=%#x : RAW_INTR_STAT=%#x :
INTR_STAT=%#x\n",
enabled, slave_activity, raw_stat, stat);
@@ -188,11 +188,9 @@ static int i2c_dw_irq_handler_slave(struct dw_i2c_dev *dev)
val);
}
regmap_read(dev->map, DW_IC_CLR_RD_REQ, &tmp);
- stat = i2c_dw_read_clear_intrbits_slave(dev);
} else {
regmap_read(dev->map, DW_IC_CLR_RD_REQ, &tmp);
regmap_read(dev->map, DW_IC_CLR_RX_UNDER, &tmp);
- stat = i2c_dw_read_clear_intrbits_slave(dev);
}
if (!i2c_slave_event(dev->slave,
I2C_SLAVE_READ_REQUESTED,
@@ -207,7 +205,6 @@ static int i2c_dw_irq_handler_slave(struct dw_i2c_dev *dev)
regmap_read(dev->map, DW_IC_CLR_RX_DONE, &tmp);
i2c_slave_event(dev->slave, I2C_SLAVE_STOP, &val);
- stat = i2c_dw_read_clear_intrbits_slave(dev);
return 1;
}
@@ -219,7 +216,6 @@ static int i2c_dw_irq_handler_slave(struct dw_i2c_dev *dev)
dev_vdbg(dev->dev, "Byte %X acked!", val);
} else {
i2c_slave_event(dev->slave, I2C_SLAVE_STOP, &val);
- stat = i2c_dw_read_clear_intrbits_slave(dev);
}
return 1;
@@ -230,7 +226,6 @@ static irqreturn_t i2c_dw_isr_slave(int this_irq, void
*dev_id)
struct dw_i2c_dev *dev = dev_id;
int ret;
- i2c_dw_read_clear_intrbits_slave(dev);
ret = i2c_dw_irq_handler_slave(dev);
if (ret > 0)
complete(&dev->cmd_complete);
--
2.17.1
Re: [PATCH 1/3] mwifiex: disable ps_mode explicitly by default instead
On Thu, 2020-10-29 at 11:25 -0700, Brian Norris wrote: > On Wed, Oct 28, 2020 at 7:04 PM Tsuchiya Yuto wrote: > > > > On Microsoft Surface devices (PCIe-88W8897), the ps_mode causes > > connection unstable, especially with 5GHz APs. Then, it eventually causes > > fw crash. > > > > This commit disables ps_mode by default instead of enabling it. > > > > Required code is extracted from mwifiex_drv_set_power(). > > > > Signed-off-by: Tsuchiya Yuto > > You should read up on WIPHY_FLAG_PS_ON_BY_DEFAULT and > CONFIG_CFG80211_DEFAULT_PS, and set/respect those appropriately (hint: > mwifiex sets WIPHY_FLAG_PS_ON_BY_DEFAULT, and your patch makes this a > lie). Also, this seems like a quirk that you haven't properly worked > out -- if you're working on a quirk framework in your other series, > you should just key into that. Thanks for the review! I didn't know about the flag, much appreciated. By setting the flag to false explicitly, indeed userspace doesn't try to enable power_save now at least for this short amount of time. I wonder if I can drop the second patch (adding module parameter) now. But I still want to make sure that power_save won't be enabled by userspace tools by default. Regarding quirks, I also don't want to break existing users. So, of course I can try to use the quirk framework if we really can't fix the firmware. > For the record, Chrome OS supports plenty of mwifiex systems with 8897 > (SDIO only) and 8997 (PCIe), with PS enabled, and you're hurting > those. Your problem sounds to be exclusively a problem with the PCIe > 8897 firmware. Actually, I already know that some Chromebooks use these mwifiex cards (but not out PCIe-88W8897) because I personally like chromiumos. I'm always wondering what is the difference. If the difference is firmware, our PCIe-88W8897 firmware should really be fixed instead of this stupid series. Yes, I'm sorry that I know this series is just a stupid one but I have to send this anyway because this stability issue has not been fixed for a long time. I should have added this buglink to every commit as well: BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=109681 If the firmware can't be fixed, I'm afraid I have to go this way. It makes no sense to keep enabling power_save for the affected devices if we know it's broken. > As-is, NAK. > > Brian
[PATCH 2/2] i2c: designware: slave should do WRITE_REQUESTED before WRITE_RECEIVED
Sometimes we would get the following flow when doing an i2cset:
0x1 STATUS SLAVE_ACTIVITY=0x1 : RAW_INTR_STAT=0x514 : INTR_STAT=0x4
I2C_SLAVE_WRITE_RECEIVED
0x1 STATUS SLAVE_ACTIVITY=0x0 : RAW_INTR_STAT=0x714 : INTR_STAT=0x204
I2C_SLAVE_WRITE_REQUESTED
I2C_SLAVE_WRITE_RECEIVED
Documentation/i2c/slave-interface.rst says that I2C_SLAVE_WRITE_REQUESTED,
which is mandatory, should be sent while the data did not arrive yet. It
means in a write-request I2C_SLAVE_WRITE_REQUESTED should be reported
before any I2C_SLAVE_WRITE_RECEIVED.
By the way, I2C_SLAVE_STOP didn't be reported in the above case because
DW_IC_INTR_STAT was not 0x200.
dev->status can be used to record the current state, especially Designware
I2C controller has no interrupts to identify a write-request. This patch
makes not only I2C_SLAVE_WRITE_REQUESTED been reported first when
IC_INTR_RX_FULL is rising and dev->status isn't STATUS_WRITE_IN_PROGRESS
but also I2C_SLAVE_STOP been reported when a STOP condition is received.
Signed-off-by: Michael Wu
---
drivers/i2c/busses/i2c-designware-slave.c | 45 +--
1 file changed, 18 insertions(+), 27 deletions(-)
diff --git a/drivers/i2c/busses/i2c-designware-slave.c
b/drivers/i2c/busses/i2c-designware-slave.c
index 13de01a0f75f..0d15f4c1e9f7 100644
--- a/drivers/i2c/busses/i2c-designware-slave.c
+++ b/drivers/i2c/busses/i2c-designware-slave.c
@@ -172,26 +172,25 @@ static int i2c_dw_irq_handler_slave(struct dw_i2c_dev
*dev)
"%#x STATUS SLAVE_ACTIVITY=%#x : RAW_INTR_STAT=%#x :
INTR_STAT=%#x\n",
enabled, slave_activity, raw_stat, stat);
- if ((stat & DW_IC_INTR_RX_FULL) && (stat & DW_IC_INTR_STOP_DET))
- i2c_slave_event(dev->slave, I2C_SLAVE_WRITE_REQUESTED, &val);
+ if (stat & DW_IC_INTR_RX_FULL) {
+ if (dev->status != STATUS_WRITE_IN_PROGRESS) {
+ dev->status = STATUS_WRITE_IN_PROGRESS;
+ i2c_slave_event(dev->slave, I2C_SLAVE_WRITE_REQUESTED,
+ &val);
+ }
+
+ regmap_read(dev->map, DW_IC_DATA_CMD, &tmp);
+ val = tmp;
+ if (!i2c_slave_event(dev->slave, I2C_SLAVE_WRITE_RECEIVED,
+&val))
+ dev_vdbg(dev->dev, "Byte %X acked!", val);
+ }
if (stat & DW_IC_INTR_RD_REQ) {
if (slave_activity) {
- if (stat & DW_IC_INTR_RX_FULL) {
- regmap_read(dev->map, DW_IC_DATA_CMD, &tmp);
- val = tmp;
-
- if (!i2c_slave_event(dev->slave,
-I2C_SLAVE_WRITE_RECEIVED,
-&val)) {
- dev_vdbg(dev->dev, "Byte %X acked!",
-val);
- }
- regmap_read(dev->map, DW_IC_CLR_RD_REQ, &tmp);
- } else {
- regmap_read(dev->map, DW_IC_CLR_RD_REQ, &tmp);
- regmap_read(dev->map, DW_IC_CLR_RX_UNDER, &tmp);
- }
+ regmap_read(dev->map, DW_IC_CLR_RD_REQ, &tmp);
+
+ dev->status = STATUS_READ_IN_PROGRESS;
if (!i2c_slave_event(dev->slave,
I2C_SLAVE_READ_REQUESTED,
&val))
@@ -203,18 +202,10 @@ static int i2c_dw_irq_handler_slave(struct dw_i2c_dev
*dev)
if (!i2c_slave_event(dev->slave, I2C_SLAVE_READ_PROCESSED,
&val))
regmap_read(dev->map, DW_IC_CLR_RX_DONE, &tmp);
-
- i2c_slave_event(dev->slave, I2C_SLAVE_STOP, &val);
- return 1;
}
- if (stat & DW_IC_INTR_RX_FULL) {
- regmap_read(dev->map, DW_IC_DATA_CMD, &tmp);
- val = tmp;
- if (!i2c_slave_event(dev->slave, I2C_SLAVE_WRITE_RECEIVED,
-&val))
- dev_vdbg(dev->dev, "Byte %X acked!", val);
- } else {
+ if (stat & DW_IC_INTR_STOP_DET) {
+ dev->status = STATUS_IDLE;
i2c_slave_event(dev->slave, I2C_SLAVE_STOP, &val);
}
--
2.17.1
Re: [PATCH v8 1/4] SFH: Add maintainers and documentation for AMD SFH based on HID framework
On Sat, 10 Oct 2020, Sandeep Singh wrote:
> From: Sandeep Singh
>
> Add Maintainers for AMD SFH(SENSOR FUSION HUB) Solution and work flow
> document.
>
> Co-developed-by: Nehal Shah
> Signed-off-by: Nehal Shah
> Signed-off-by: Sandeep Singh
> ---
> Documentation/hid/amd-sfh-hid.rst | 145 ++
> Documentation/hid/index.rst | 1 +
> MAINTAINERS | 8 ++
> 3 files changed, 154 insertions(+)
> create mode 100644 Documentation/hid/amd-sfh-hid.rst
>
I do not know where something went wrong here, but it seems that
the git commit 302f0dad8c97 ("SFH: Add maintainers and
documentation for AMD SFH based on HID framework") on next-20201030
dropped the addition of the rst file compared to this patch v8 here.
See: git show --stat 302f0dad8c97a11abcf145ff3c70
[...]
Documentation/hid/index.rst | 1 +
MAINTAINERS | 8
2 files changed, 9 insertions(+)
Hence, ./scripts/get_maintainer.pl --self-test=patterns complains:
warning: no file matchesF:Documentation/hid/amd-sfh*
Just that you know...
Lukas
Re: [RESEND PATCH] KEYS: asymmetric: Fix kerneldoc
On Thu, Oct 29, 2020 at 04:48:30PM +0100, Krzysztof Kozlowski wrote: > Fix W=1 compile warnings (invalid kerneldoc): > > crypto/asymmetric_keys/asymmetric_type.c:160: warning: Function parameter > or member 'kid1' not described in 'asymmetric_key_id_same' > crypto/asymmetric_keys/asymmetric_type.c:160: warning: Function parameter > or member 'kid2' not described in 'asymmetric_key_id_same' > crypto/asymmetric_keys/asymmetric_type.c:160: warning: Excess function > parameter 'kid_1' description in 'asymmetric_key_id_same' > crypto/asymmetric_keys/asymmetric_type.c:160: warning: Excess function > parameter 'kid_2' description in 'asymmetric_key_id_same' > > Signed-off-by: Krzysztof Kozlowski > Acked-by: Randy Dunlap > --- Reviewed-by: Jarkko Sakkinen > crypto/asymmetric_keys/asymmetric_type.c | 6 -- > 1 file changed, 4 insertions(+), 2 deletions(-) > > diff --git a/crypto/asymmetric_keys/asymmetric_type.c > b/crypto/asymmetric_keys/asymmetric_type.c > index 33e77d846caa..ad8af3d70ac0 100644 > --- a/crypto/asymmetric_keys/asymmetric_type.c > +++ b/crypto/asymmetric_keys/asymmetric_type.c > @@ -152,7 +152,8 @@ EXPORT_SYMBOL_GPL(asymmetric_key_generate_id); > > /** > * asymmetric_key_id_same - Return true if two asymmetric keys IDs are the > same. > - * @kid_1, @kid_2: The key IDs to compare > + * @kid1: The key ID to compare > + * @kid2: The key ID to compare > */ > bool asymmetric_key_id_same(const struct asymmetric_key_id *kid1, > const struct asymmetric_key_id *kid2) > @@ -168,7 +169,8 @@ EXPORT_SYMBOL_GPL(asymmetric_key_id_same); > /** > * asymmetric_key_id_partial - Return true if two asymmetric keys IDs > * partially match > - * @kid_1, @kid_2: The key IDs to compare > + * @kid1: The key ID to compare > + * @kid2: The key ID to compare > */ > bool asymmetric_key_id_partial(const struct asymmetric_key_id *kid1, > const struct asymmetric_key_id *kid2) > -- > 2.25.1 > > /Jarkko
Re: [PATCH v2 2/2] init/Kconfig: Increase default log buffer size from 128 KB to 512 KB
On Tue, Aug 11, 2020 at 12:55 PM Petr Mladek wrote:
> On Tue 2020-08-11 11:29:24, Paul Menzel wrote:
> > Commit f17a32e97e (let LOG_BUF_SHIFT default to 17) from 2008 was the
> > last time, the the default log buffer size bump was increased.
> >
> > Machines have evolved, and on current hardware, enough memory is
> > present, and some devices have over 200 PCI devices, like a two socket
> > Skylake-E server, resulting a lot of lines.
> >
> > Therefore, increase the default from 128 KB to 512 KB. Anyone, with
> > limited memory, can still lower it.
> >
> > --- a/init/Kconfig
> > +++ b/init/Kconfig
> > @@ -681,9 +681,9 @@ config IKHEADERS
> > kheaders.ko is built which can be loaded on-demand to get access to
> > headers.
> >
> > config LOG_BUF_SHIFT
> > - int "Kernel log buffer size (16 => 64KB, 17 => 128KB)"
> > + int "Kernel log buffer size (17 => 128KB, 19 => 512KB)"
> > range 12 25
> > - default 17
> > + default 19
> > depends on PRINTK
> > help
> > Select the minimal kernel log buffer size as a power of 2.
>
> Honestly, I do not have experience with changing the defaults. People
> hacking small devices might complain. Well, this can be solved
> by increasing the default only when BASE_FULL is set.
>
> I am personally fine with increasing the default when BASE_FULL
> is set. The amount of messages is growing over time because of
> increasing complexity of both the hardware and software.
> Fortunately also the amount of available memory is growing.
Note that making this change means that some of the embedded
defconfigs may need to gain a CONFIG_LOG_BUF_SHIFT=17
line...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH] arm64/smp: Move rcu_cpu_starting() earlier
On Thu, Oct 29, 2020 at 09:17:35AM -0400, Qian Cai wrote: > On Thu, 2020-10-29 at 09:10 +, Will Deacon wrote: > > On Wed, Oct 28, 2020 at 02:26:14PM -0400, Qian Cai wrote: > > > The call to rcu_cpu_starting() in secondary_start_kernel() is not early > > > enough in the CPU-hotplug onlining process, which results in lockdep > > > splats as follows: > > > > > > WARNING: suspicious RCU usage > > > - > > > kernel/locking/lockdep.c:3497 RCU-list traversed in non-reader section!! > > > > > > other info that might help us debug this: > > > > > > RCU used illegally from offline CPU! > > > rcu_scheduler_active = 1, debug_locks = 1 > > > no locks held by swapper/1/0. > > > > > > Call trace: > > > dump_backtrace+0x0/0x3c8 > > > show_stack+0x14/0x60 > > > dump_stack+0x14c/0x1c4 > > > lockdep_rcu_suspicious+0x134/0x14c > > > __lock_acquire+0x1c30/0x2600 > > > lock_acquire+0x274/0xc48 > > > _raw_spin_lock+0xc8/0x140 > > > vprintk_emit+0x90/0x3d0 > > > vprintk_default+0x34/0x40 > > > vprintk_func+0x378/0x590 > > > printk+0xa8/0xd4 > > > __cpuinfo_store_cpu+0x71c/0x868 > > > cpuinfo_store_cpu+0x2c/0xc8 > > > secondary_start_kernel+0x244/0x318 > > > > > > This is avoided by moving the call to rcu_cpu_starting up near the > > > beginning of the secondary_start_kernel() function. > > > > Hmm, it's not really a move though -- we'll end up calling this thing twice > > afaict. It would be better to make sure we've called notify_cpu_starting() > > early enough. Can we do that instead? > > Paul mentioned that it is fine to call rcu_cpu_starting() multiple times, and > Peter mentioned that CPU bringup is complicated. Thus, I thought about doing > something safe here. > > I tested a bit of patch below which seems fine, but I can't tell for sure if > it > is safe. Any suggestion? No, you're right -- this does look dodgy as I think we'll end up kicking the CPU notifiers before things like CPU errata have been figured out. So I'll pick up your original patch with Paul's ack. Thanks! Will
Re: [PATCH v4 03/11] arm64: dts: ls1088a: add external MDIO device nodes
On Mon, Oct 26, 2020 at 06:09:57PM +0200, Ioana Ciornei wrote:
> Add the external MDIO device nodes found in the WRIOP global memory
> region. This is needed for management of external PHYs.
>
> Signed-off-by: Ioana Ciornei
> ---
> Changes in v2:
> - removed the 0x from the unit addresses
> Changes in v3:
> - none
> Changes in v4:
> - none
>
> arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi | 18 ++
> 1 file changed, 18 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
> b/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
> index ff5805206a28..aea42e9e947f 100644
> --- a/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
> +++ b/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
> @@ -672,6 +672,24 @@ ptp-timer@8b95000 {
> fsl,extts-fifo;
> };
>
> + emdio1: mdio@8b96000 {
> + compatible = "fsl,fman-memac-mdio";
> + reg = <0x0 0x8B96000 0x0 0x1000>;
Use lowercase for hex values.
Shawn
> + little-endian;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + status = "disabled";
> + };
> +
> + emdio2: mdio@8b97000 {
> + compatible = "fsl,fman-memac-mdio";
> + reg = <0x0 0x8B97000 0x0 0x1000>;
> + little-endian;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + status = "disabled";
> + };
> +
> cluster1_core0_watchdog: wdt@c00 {
> compatible = "arm,sp805-wdt", "arm,primecell";
> reg = <0x0 0xc00 0x0 0x1000>;
> --
> 2.28.0
>
Re: [PATCH 2/3] hwmon: ltc2992: Add support for GPIOs.
Hi,
I love your patch! Perhaps something to improve:
[auto build test WARNING on hwmon/hwmon-next]
[also build test WARNING on linus/master linux/master v5.10-rc1 next-20201029]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/alexandru-tachici-analog-com/hwmon-ltc2992-Add-support/20201029-174720
base:
https://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git
hwmon-next
config: x86_64-randconfig-r023-20201030 (attached as .config)
compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project
772aaa602383cf82795572ebcd86b0e660f3579f)
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# install x86_64 cross compiling tool for clang build
# apt-get install binutils-x86-64-linux-gnu
#
https://github.com/0day-ci/linux/commit/f74af3cc59b7d9de6545502e7d01df6e01f96773
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
alexandru-tachici-analog-com/hwmon-ltc2992-Add-support/20201029-174720
git checkout f74af3cc59b7d9de6545502e7d01df6e01f96773
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=x86_64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
>> drivers/hwmon/ltc2992.c:276:6: warning: no previous prototype for function
>> 'ltc2992_gpio_set_multiple' [-Wmissing-prototypes]
void ltc2992_gpio_set_multiple(struct gpio_chip *chip, unsigned long *mask,
unsigned long *bits)
^
drivers/hwmon/ltc2992.c:276:1: note: declare 'static' if the function is not
intended to be used outside of this translation unit
void ltc2992_gpio_set_multiple(struct gpio_chip *chip, unsigned long *mask,
unsigned long *bits)
^
static
1 warning generated.
vim +/ltc2992_gpio_set_multiple +276 drivers/hwmon/ltc2992.c
275
> 276 void ltc2992_gpio_set_multiple(struct gpio_chip *chip, unsigned long
> *mask, unsigned long *bits)
277 {
278 struct ltc2992_state *st = gpiochip_get_data(chip);
279 unsigned long gpio_ctrl_io = 0;
280 unsigned long gpio_ctrl = 0;
281 unsigned int gpio_nr;
282
283 for_each_set_bit(gpio_nr, mask, LTC2992_GPIO_NR) {
284 if (gpio_nr < 3)
285
assign_bit(ltc2992_gpio_addr_map[gpio_nr].ctrl_bit, &gpio_ctrl_io, true);
286
287 if (gpio_nr == 3)
288
assign_bit(ltc2992_gpio_addr_map[gpio_nr].ctrl_bit, &gpio_ctrl, true);
289 }
290
291 mutex_lock(&st->gpio_mutex);
292 ltc2992_write_reg(st, LTC2992_GPIO_IO_CTRL, 1, gpio_ctrl_io);
293 ltc2992_write_reg(st, LTC2992_GPIO_CTRL, 1, gpio_ctrl);
294 mutex_unlock(&st->gpio_mutex);
295 }
296
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
[PATCH] crypto: arm64 - move const after static
Fixed the WARNING: Move const after static - use 'static const u8'
Signed-off-by: Tian Tao
---
arch/arm64/crypto/aes-ce-glue.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/crypto/aes-ce-glue.c b/arch/arm64/crypto/aes-ce-glue.c
index 56a5f6f..8ba6f04 100644
--- a/arch/arm64/crypto/aes-ce-glue.c
+++ b/arch/arm64/crypto/aes-ce-glue.c
@@ -77,7 +77,7 @@ int ce_aes_expandkey(struct crypto_aes_ctx *ctx, const u8
*in_key,
/*
* The AES key schedule round constants
*/
- static u8 const rcon[] = {
+ static const u8 rcon[] = {
0x01, 0x02, 0x04, 0x08, 0x10, 0x20, 0x40, 0x80, 0x1b, 0x36,
};
--
2.7.4
Re: [PATCH] mtd: rawnand: stm32_fmc2: fix broken ECC
Hi Christophe,
Christophe Kerello wrote on Thu, 29 Oct
2020 17:38:12 +0100:
> Since commit d7157ff49a5b ("mtd: rawnand: Use the ECC framework user
> input parsing bits"), ECC are broken in FMC2 driver in case of
> nand-ecc-step-size and nand-ecc-strength are not set in the device tree.
> The default user configuration set in FMC2 driver is lost when
> rawnand_dt_init function is called. To avoid to lose the default user
> configuration, it is needed to move it in the new user_conf structure.
>
> Signed-off-by: Christophe Kerello
> Fixes: d7157ff49a5b ("mtd: rawnand: Use the ECC framework user input parsing
> bits")
> ---
> drivers/mtd/nand/raw/stm32_fmc2_nand.c | 8 +---
> 1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/mtd/nand/raw/stm32_fmc2_nand.c
> b/drivers/mtd/nand/raw/stm32_fmc2_nand.c
> index b31a581..dc86ac9 100644
> --- a/drivers/mtd/nand/raw/stm32_fmc2_nand.c
> +++ b/drivers/mtd/nand/raw/stm32_fmc2_nand.c
> @@ -1846,6 +1846,7 @@ static int stm32_fmc2_nfc_probe(struct platform_device
> *pdev)
> struct resource *res;
> struct mtd_info *mtd;
> struct nand_chip *chip;
> + struct nand_device *nanddev;
> struct resource cres;
> int chip_cs, mem_region, ret, irq;
> int start_region = 0;
> @@ -1952,10 +1953,11 @@ static int stm32_fmc2_nfc_probe(struct
> platform_device *pdev)
> chip->options |= NAND_BUSWIDTH_AUTO | NAND_NO_SUBPAGE_WRITE |
>NAND_USES_DMA;
>
> - /* Default ECC settings */
> + /* Default ECC user settings */
> chip->ecc.engine_type = NAND_ECC_ENGINE_TYPE_ON_HOST;
> - chip->ecc.size = FMC2_ECC_STEP_SIZE;
> - chip->ecc.strength = FMC2_ECC_BCH8;
> + nanddev = mtd_to_nanddev(mtd);
> + nanddev->ecc.user_conf.step_size = FMC2_ECC_STEP_SIZE;
> + nanddev->ecc.user_conf.strength = FMC2_ECC_BCH8;
>
> /* Scan to find existence of the device */
> ret = nand_scan(chip, nand->ncs);
Sorry for breaking the driver with this change, but now I think we
should have all ECC related bits in ->attach() instead of ->probe().
The ->attach() hook is called during the nand_scan() operation and at
this point the chip's requirements/layout are known (not before). I
know that certain controllers don't really care about that, here your
simply hardcode these two fields and you don't need to know anything
about the chip's properties. But as a bid to harmonize all drivers with
the target of a generic ECC engine in mind, I think it's now time to
move these three lines (chip->ecc.* = ...) at the top of ->attach().
Also, these fields should have been populated by the core so perhaps
the best approach is to check if the user requirements are synced with
the controller's capabilities and error out otherwise?
We plan to send a fixes PR for -rc2, if the v2 arrives today I'll
integrate it.
Thanks,
Miquèl
Re: [Outreachy kernel] [PATCH] drm/amdgpu: use DEFINE_DEBUGFS_ATTRIBUTE with debugfs_create_file_unsafe()
On Fri, Oct 30, 2020 at 01:47:05PM +0530, Sumera Priyadarsini wrote: > On Fri, 30 Oct, 2020, 1:32 PM Greg KH, wrote: > > > On Fri, Oct 30, 2020 at 01:27:16PM +0530, Deepak R Varma wrote: > > > On Fri, Oct 30, 2020 at 08:11:20AM +0100, Greg KH wrote: > > > > On Fri, Oct 30, 2020 at 08:52:45AM +0530, Deepak R Varma wrote: > > > > > Using DEFINE_DEBUGFS_ATTRIBUTE macro with > > debugfs_create_file_unsafe() > > > > > function in place of the debugfs_create_file() function will make the > > > > > file operation struct "reset" aware of the file's lifetime. > > Additional > > > > > details here: > > https://lists.archive.carbon60.com/linux/kernel/2369498 > > > > > > > > > > Issue reported by Coccinelle script: > > > > > scripts/coccinelle/api/debugfs/debugfs_simple_attr.cocci > > > > > > > > > > Signed-off-by: Deepak R Varma > > > > > --- > > > > > Please Note: This is a Outreachy project task patch. > > > > > > > > > > drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 20 > > ++-- > > > > > 1 file changed, 10 insertions(+), 10 deletions(-) > > > > > > > > > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c > > b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c > > > > > index 2d125b8b15ee..f076b1ba7319 100644 > > > > > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c > > > > > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c > > > > > @@ -1551,29 +1551,29 @@ static int amdgpu_debugfs_sclk_set(void > > *data, u64 val) > > > > > return 0; > > > > > } > > > > > > > > > > -DEFINE_SIMPLE_ATTRIBUTE(fops_ib_preempt, NULL, > > > > > - amdgpu_debugfs_ib_preempt, "%llu\n"); > > > > > +DEFINE_DEBUGFS_ATTRIBUTE(fops_ib_preempt, NULL, > > > > > + amdgpu_debugfs_ib_preempt, "%llu\n"); > > > > > > > > Are you sure this is ok? Do these devices need this additional > > > > "protection"? Do they have the problem that these macros were written > > > > for? > > > > > > > > Same for the other patches you just submitted here, I think you need to > > > > somehow "prove" that these changes are necessary, checkpatch isn't able > > > > to determine this all the time. > > > > > > Hi Greg, > > > Based on my understanding, the current function debugfs_create_file() > > > adds an overhead of lifetime managing proxy for such fop structs. This > > > should be applicable to these set of drivers as well. Hence I think this > > > change will be useful. > > > > Why do these drivers need these changes? Are these files dynamically > > removed from the system at random times? > > > > There is a reason we didn't just do a global search/replace for this in > > the kernel when the new functions were added, so I don't know why > > checkpatch is now saying it must be done. > > > > Hi, > > Sorry to jump in on the thread this way, but what exactly does a 'lifetime > managing proxy' for file operations mean? I am trying to understand how > DEFINE_DEBUGFS_ATTRIBUTE changes things wrt debug_ fs file operations but > can't find many resources. :( It means that the debugfs core can handle debugfs files being removed from the system while they are still open when they were created by a driver/module that is now unloaded from memory. This is only an issue for drivers that manage devices that have unknown lifespans (i.e. they can be yanked out of the system at any time, and the memory for those debugfs files can be freed). For the entire DRM/GPU subsystem, I strongly doubt this is the case. > Please let me know if I should be asking this in a different mailing > list/irc instead. > > The change seems to be suggested by a coccinelle script. I know, and I don't think that script knows the nuances behind this, as, again, we would have just done a global search/replace for this when the debugfs fixes went into the kernel. thanks, greg k-h
Re: [Outreachy kernel] [PATCH] drm/amdgpu: use DEFINE_DEBUGFS_ATTRIBUTE with debugfs_create_file_unsafe()
On Fri, Oct 30, 2020 at 09:00:04AM +0100, Christian König wrote: > Am 30.10.20 um 08:57 schrieb Deepak R Varma: > > On Fri, Oct 30, 2020 at 08:11:20AM +0100, Greg KH wrote: > > > On Fri, Oct 30, 2020 at 08:52:45AM +0530, Deepak R Varma wrote: > > > > Using DEFINE_DEBUGFS_ATTRIBUTE macro with debugfs_create_file_unsafe() > > > > function in place of the debugfs_create_file() function will make the > > > > file operation struct "reset" aware of the file's lifetime. Additional > > > > details here: > > > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.archive.carbon60.com%2Flinux%2Fkernel%2F2369498&data=04%7C01%7Cchristian.koenig%40amd.com%7Cddd7a6ac8164415a639708d87ca97004%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637396414464384011%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=o6GOHvMxNMuOPlC4nhDyURCHBLqfQZhYQq%2BiIMt3D3s%3D&reserved=0 > > > > > > > > Issue reported by Coccinelle script: > > > > scripts/coccinelle/api/debugfs/debugfs_simple_attr.cocci > > > > > > > > Signed-off-by: Deepak R Varma > > > > --- > > > > Please Note: This is a Outreachy project task patch. > > > > > > > > drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 20 ++-- > > > > 1 file changed, 10 insertions(+), 10 deletions(-) > > > > > > > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c > > > > b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c > > > > index 2d125b8b15ee..f076b1ba7319 100644 > > > > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c > > > > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c > > > > @@ -1551,29 +1551,29 @@ static int amdgpu_debugfs_sclk_set(void *data, > > > > u64 val) > > > > return 0; > > > > } > > > > -DEFINE_SIMPLE_ATTRIBUTE(fops_ib_preempt, NULL, > > > > - amdgpu_debugfs_ib_preempt, "%llu\n"); > > > > +DEFINE_DEBUGFS_ATTRIBUTE(fops_ib_preempt, NULL, > > > > +amdgpu_debugfs_ib_preempt, "%llu\n"); > > > Are you sure this is ok? Do these devices need this additional > > > "protection"? Do they have the problem that these macros were written > > > for? > > > > > > Same for the other patches you just submitted here, I think you need to > > > somehow "prove" that these changes are necessary, checkpatch isn't able > > > to determine this all the time. > > Hi Greg, > > Based on my understanding, the current function debugfs_create_file() > > adds an overhead of lifetime managing proxy for such fop structs. This > > should be applicable to these set of drivers as well. Hence I think this > > change will be useful. > > Well since this is only created once per device instance I don't really care > about this little overhead. > > But what exactly is debugfs doing or not doing here? It is trying to save drivers from having debugfs files open that point to memory that can go away at any time. For graphics devices, I doubt that is the case. thanks, greg k-h
Re: [RESENDPATCH v15 2/2] mtd: rawnand: Add NAND controller support on Intel LGM SoC
Hello,
> >> +static const struct nand_controller_ops ebu_nand_controller_ops = {
> >> + .attach_chip = ebu_nand_attach_chip,
> >> + .setup_interface = ebu_nand_set_timings,
> >> + .exec_op = ebu_nand_exec_op,
> >> +};
> >> +
> >> +static void ebu_dma_cleanup(struct ebu_nand_controller *ebu_host)
> >> +{
> >> + if (ebu_host->dma_rx)
> >> + dma_release_channel(ebu_host->dma_rx);
> >> +
> >> + if (ebu_host->dma_tx)
> >> + dma_release_channel(ebu_host->dma_tx);
> >> +}
> >> +
> >> +static int ebu_nand_probe(struct platform_device *pdev)
> >> +{
> >> + struct device *dev = &pdev->dev;
> >> + struct ebu_nand_controller *ebu_host;
> >> + struct nand_chip *nand;
> >> + struct mtd_info *mtd;
> >> + struct resource *res;
> >> + char *resname;
> >> + int ret, i;
> >> + u32 reg;
> >> +
> >> + ebu_host = devm_kzalloc(dev, sizeof(*ebu_host), GFP_KERNEL);
> >> + if (!ebu_host)
> >> + return -ENOMEM;
> >> +
> >> + ebu_host->dev = dev;
> >> + nand_controller_init(&ebu_host->controller);
> >> +
> >> + res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "ebunand");
> >> + ebu_host->ebu = devm_ioremap_resource(&pdev->dev, res);
> >> + if (IS_ERR(ebu_host->ebu))
> >> + return PTR_ERR(ebu_host->ebu);
> >> +
> >> + res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "hsnand");
> >> + ebu_host->hsnand = devm_ioremap_resource(&pdev->dev, res);
> >> + if (IS_ERR(ebu_host->hsnand))
> >> + return PTR_ERR(ebu_host->hsnand);
> >> +
> >> + ret = device_property_read_u32(dev, "nand,cs", ®);
> >
> > There is no nand,cs property. Use 'reg' instead.
> Noted.
> >
> >> + if (ret) {
> >> + dev_err(dev, "failed to get chip select: %d\n", ret);
> >> + return ret;
> >> + }
> >> + ebu_host->cs_num = reg;
> >
> > The following for loop is weird, above you can only store a single cs
> > number, while below you seem to reserve serveral memory areas. Please
> > clarify this code.
> This IP supports 2 chip select for 2 different memory regions so we used the
> below for loop, as per reviewers comment updated.
>EBU_CS0_BASE 0xE1C0_ (Memory-Mapped)
>EBU_CS0_IO_BASE 0x1740_ (FPI I/O Mapped)
>
> EBU_CS1_BASE 0xE140_ (Memory-Mapped)
> EBU_CS1_IO_BASE 0x17C0_ (FPI I/O Mapped)
Please make a difference between, "there are two CS, either can be
picked but we can use only one in this driver" or "there are two CS,
one or both can be used". You can start with supporting a single CS (no
matter which one is picked by the user with the reg property) but in
this case there is no such for loop because only 1 CS is used. Or you
can decide that both CS can be populated and in this case you must
handle this in ->select_chip().
>
> >
> >> +
> >> + for (i = 0; i < MAX_CS; i++) {
> >> + resname = devm_kasprintf(dev, GFP_KERNEL, "nand_cs%d", i);
> >> + res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
> >> + resname);
> >> + ebu_host->cs[i].chipaddr = devm_ioremap_resource(dev, res);
> >> + ebu_host->cs[i].nand_pa = res->start;
> >> + if (IS_ERR(ebu_host->cs[i].chipaddr))
> >> + return PTR_ERR(ebu_host->cs[i].chipaddr);
> >> + }
> >> +
> >> + ebu_host->clk = devm_clk_get(dev, NULL);
> >> + if (IS_ERR(ebu_host->clk))
> >> + return dev_err_probe(dev, PTR_ERR(ebu_host->clk),
> >> + "failed to get clock\n");
> >> +
> >> + ret = clk_prepare_enable(ebu_host->clk);
> >> + if (ret) {
> >> + dev_err(dev, "failed to enable clock: %d\n", ret);
> >> + return ret;
> >> + }
> >> + ebu_host->clk_rate = clk_get_rate(ebu_host->clk);
> >> +
> >> + ebu_host->dma_tx = dma_request_chan(dev, "tx");
> >> + if (IS_ERR(ebu_host->dma_tx))
> >> + return dev_err_probe(dev, PTR_ERR(ebu_host->dma_tx),
> >> + "failed to request DMA tx chan!.\n");
> >> +
> >> + ebu_host->dma_rx = dma_request_chan(dev, "rx");
> >> + if (IS_ERR(ebu_host->dma_rx))
> >> + return dev_err_probe(dev, PTR_ERR(ebu_host->dma_rx),
> >> + "failed to request DMA rx chan!.\n");
> >> +
> >> + for (i = 0; i < MAX_CS; i++) {
> >> + resname = devm_kasprintf(dev, GFP_KERNEL, "addr_sel%d", i);
> >> + res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
> >> + resname);
> >> + if (!res)
> >> + return -EINVAL;
> >> + ebu_host->cs[i].addr_sel = res->start;
> >> + writel(ebu_host->cs[i].addr_sel | EBU_ADDR_MASK(5) |
> >> + EBU_ADDR_SEL_REGEN, ebu_host->ebu + EBU_ADDR_SEL(i));
> >> + }
> >> +
> >> + nand_set_flash_node(&ebu_host->chip, dev->of_node);
> >> + if (!mtd->name) {
> >> + dev_err(ebu_host->dev, "NAND label property is mandatory\n");
>
Re: [PATCH -V2 1/2] mempolicy: Rename MPOL_F_MORON to MPOL_F_MOPRON
On Fri 30-10-20 15:27:51, Huang, Ying wrote: > Michal Hocko writes: > > > On Wed 28-10-20 10:34:10, Huang Ying wrote: > >> To follow code-of-conduct better. > > > > This is changing a user visible interface and any userspace which refers > > to the existing name will fail to compile unless I am missing something. > > Although these flags are put in uapi, I found these flags are actually > internal flags used in "flags" field of struct mempolicy, they are never > used as flags for any user space API. I guess they are placed in uapi > header file to guarantee they aren't conflict with MPOL_MODE_FLAGS. You are right. I have missed that. The comment in the header even explains that. Anyway the placement is rather unusual and I think that those flags do not belong there. > > Have you checked how many applications would be affected? > > Based on above analysis, I think there is no application that will be > affected. > > > Btw I find "follow CoC better" a very weak argument without further > > explanation. > > That is the only reason for the patch. If nobody thinks the change is > necessary, I can just drop the patch. Well, to be honest I do not see any problem with the naming. -- Michal Hocko SUSE Labs
