[PATCH] staging: rtl8723bs: Remove unneeded function argument for init_addba_retry_timer
init_addba_retry_timer does not use padapter, so only keep psta
Signed-off-by: Hariprasad Kelam
---
drivers/staging/rtl8723bs/core/rtw_sta_mgt.c | 2 +-
drivers/staging/rtl8723bs/include/rtw_mlme_ext.h | 2 +-
drivers/staging/rtl8723bs/os_dep/mlme_linux.c| 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/rtl8723bs/core/rtw_sta_mgt.c
b/drivers/staging/rtl8723bs/core/rtw_sta_mgt.c
index bdc52d8..39c3482 100644
--- a/drivers/staging/rtl8723bs/core/rtw_sta_mgt.c
+++ b/drivers/staging/rtl8723bs/core/rtw_sta_mgt.c
@@ -262,7 +262,7 @@ struct sta_info *rtw_alloc_stainfo(struct
sta_priv *pstapriv, u8 *hwaddr)
)
);
- init_addba_retry_timer(pstapriv->padapter, psta);
+ init_addba_retry_timer(psta);
/* for A-MPDU Rx reordering buffer control */
for (i = 0; i < 16 ; i++) {
diff --git a/drivers/staging/rtl8723bs/include/rtw_mlme_ext.h
b/drivers/staging/rtl8723bs/include/rtw_mlme_ext.h
index 733bb94..186f4f5 100644
--- a/drivers/staging/rtl8723bs/include/rtw_mlme_ext.h
+++ b/drivers/staging/rtl8723bs/include/rtw_mlme_ext.h
@@ -539,7 +539,7 @@ int init_mlme_ext_priv(struct adapter *padapter);
int init_hw_mlme_ext(struct adapter *padapter);
void free_mlme_ext_priv (struct mlme_ext_priv *pmlmeext);
extern void init_mlme_ext_timer(struct adapter *padapter);
-extern void init_addba_retry_timer(struct adapter *padapter, struct sta_info
*psta);
+extern void init_addba_retry_timer(struct sta_info *psta);
extern struct xmit_frame *alloc_mgtxmitframe(struct xmit_priv *pxmitpriv);
/* void fill_fwpriv(struct adapter *padapter, struct fw_priv *pfwpriv); */
diff --git a/drivers/staging/rtl8723bs/os_dep/mlme_linux.c
b/drivers/staging/rtl8723bs/os_dep/mlme_linux.c
index 52a5b31..038036d 100644
--- a/drivers/staging/rtl8723bs/os_dep/mlme_linux.c
+++ b/drivers/staging/rtl8723bs/os_dep/mlme_linux.c
@@ -179,7 +179,7 @@ void rtw_report_sec_ie(struct adapter *adapter, u8
authmode, u8 *sec_ie)
}
}
-void init_addba_retry_timer(struct adapter *padapter, struct sta_info *psta)
+void init_addba_retry_timer(struct sta_info *psta)
{
timer_setup(>addba_retry_timer, addba_timer_hdl, 0);
}
--
2.7.4
Re: [GIT pull] core/urgent for 5.3-rc2
The pull request you sent on Sat, 27 Jul 2019 23:26:14 -: > git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git > core-urgent-for-linus has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/13fbe991b5b1bbb52ede39be11d5c196721349bf Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT pull] sched/urgent for 5.3-rc2
The pull request you sent on Sat, 27 Jul 2019 23:26:14 -: > git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git > sched-urgent-for-linus has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/e24ce84e85abe50811f33caecbf104b7d9dffb03 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT pull] x86/urgent for 5.3-rc2
The pull request you sent on Sat, 27 Jul 2019 23:26:14 -: > git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86-urgent-for-linus has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/a9815a4fa2fd297cab9fa7a12161b16657290293 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT pull] perf/urgent for 5.3-rc2
The pull request you sent on Sat, 27 Jul 2019 23:26:14 -: > git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git > perf-urgent-for-linus has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/750991f9af5b4019fd0232c23a4815682ff91021 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT pull] locking/urgent for 5.3-rc2
The pull request you sent on Sat, 27 Jul 2019 23:26:14 -: > git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git > locking-urgent-for-linus has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/431f288ed730abfaca5cb73f7e0a2d04459aa65c Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
PAYMENT CENTRE ATM CARD
Attn: Fund Beneficiary This is the 2nd time i am sending you this notification letter regarding your abandoned ATM Visa Card valued sum of US$9,500.000.00 and i have not received any positive respond from you or asking a suggestion on how you wish to receive your ATM Visa Card. Once again; I am Mr. Martins Bright, the new director of ATM Head of Operation United Bank For Africa PLC, I resumed to this office on the 2nd of November 2018 and during my official research I discovered an abandoned ATM Visa card valued sum of $9,500.000.00 belonging to you as the rightfully intimate beneficiary. I tried to know why this ATM Visa Card has not been released to you but I was told by the UBA Bank management that the former director of ATM head of operation that left this office three months ago withhold your Card for his own personal use without knowing that his evil plans towards diverting your fund will be discovered. Now that your ATM Visa Card is still available and ready for your receiving, you can come down here to our Bank to pick up your Card direct from my office or alternatively it can be arranged ship to your address through any registered reliable Courier Service Company that you will take care of the Courier Charge,hope it is cleared and accepted by you? In this case, you are required to forward the following information: 1, Your full name and address:--- 2, Your direct phone number for easy communication:--- 3, Identification card or passport:- 4, Your Occupation:- Your direct telephone number and address will be needed and more details of your ATM Visa Card payment will be made known to you as soon as I receive your swift positive response. Contact me on this below email address; E-mail address: ( yesben...@gmail.com ) Telephone number:=== (+234) 701638756 Contact person:=== Mr.Martins Bright Do not hesitate to call me on (+234) 7016738790 as soon as you read this mail. Thanks for your co-operation and i wait for your kind positive respond. Yours Faithfully, Mr.Martins Bright PAYMENT CENTRE ATM CARD
Re: [PATCH] sched/core: Don't use dying mm as active_mm for kernel threads
Hi Waiman,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on linus/master]
[cannot apply to v5.3-rc1 next-20190726]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Waiman-Long/sched-core-Don-t-use-dying-mm-as-active_mm-for-kernel-threads/20190728-101948
config: i386-allnoconfig (attached as .config)
compiler: gcc-7 (Debian 7.4.0-10) 7.4.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot
All errors (new ones prefixed by >>):
kernel/sched/core.c: In function 'context_switch':
>> kernel/sched/core.c:3240:18: error: 'struct mm_struct' has no member named
>> 'owner'
if (!mm && oldmm->owner) {
^~
vim +3240 kernel/sched/core.c
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
Re: [PATCH] Kbuild: Handle PREEMPT_RT for version string and magic
Hi Thomas, On Sat, Jul 27, 2019 at 5:49 AM Thomas Gleixner wrote: > > Update the build scripts and the version magic to reflect when > CONFIG_PREEMPT_RT is enabled in the same way as CONFIG_PREEMPT is treated. > > The resulting version strings: > > Linux m 5.3.0-rc1+ #100 SMP Fri Jul 26 ... > Linux m 5.3.0-rc1+ #101 SMP PREEMPT Fri Jul 26 ... > Linux m 5.3.0-rc1+ #102 SMP PREEMPT_RT Fri Jul 26 ... > > The module vermagic: > > 5.3.0-rc1+ SMP mod_unload modversions > 5.3.0-rc1+ SMP preempt mod_unload modversions > 5.3.0-rc1+ SMP preempt_rt mod_unload modversions > > Signed-off-by: Thomas Gleixner > Cc: Masahiro Yamada > Cc: Michal Marek > Cc: linux-kbu...@vger.kernel.org Since CONFIG_PREEMPTION was introduced after -rc1, I think this should be queued on top of -rc2. Just a nit below. > --- > include/linux/vermagic.h | 10 +++--- > init/Makefile|5 +++-- > scripts/Makefile.modpost |2 +- > scripts/mkcompile_h |4 +++- > 4 files changed, 14 insertions(+), 7 deletions(-) > > --- a/include/linux/vermagic.h > +++ b/include/linux/vermagic.h > @@ -7,10 +7,14 @@ > #else > #define MODULE_VERMAGIC_SMP "" > #endif > -#ifdef CONFIG_PREEMPT > -#define MODULE_VERMAGIC_PREEMPT "preempt " > +#ifdef CONFIG_PREEMPTION > +# ifdef CONFIG_PREEMPT > +# define MODULE_VERMAGIC_PREEMPT "preempt " > +# else > +# define MODULE_VERMAGIC_PREEMPT "preempt_rt " > +# endif > #else > -#define MODULE_VERMAGIC_PREEMPT "" > +# define MODULE_VERMAGIC_PREEMPT "" Maybe, is the following more readable? #if defined(CONFIG_PREEMPT_RT) #define MODULE_VERMAGIC_PREEMPT "preempt_rt " #elif defined(CONFIG_PREEMPT) #define MODULE_VERMAGIC_PREEMPT "preempt " #else #define MODULE_VERMAGIC_PREEMPT "" #endif Thanks. -- Best Regards Masahiro Yamada
Re: [PATCH] hv_sock: use HV_HYP_PAGE_SIZE instead of PAGE_SIZE_4K
Hi Himadri, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on linus/master] [cannot apply to v5.3-rc1 next-20190726] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Himadri-Pandya/hv_sock-use-HV_HYP_PAGE_SIZE-instead-of-PAGE_SIZE_4K/20190726-085229 reproduce: # apt-get install sparse # sparse version: v0.6.1-rc1-7-g2b96cd8-dirty make ARCH=x86_64 allmodconfig make C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' If you fix the issue, kindly add following tag Reported-by: kbuild test robot sparse warnings: (new ones prefixed by >>) include/linux/sched.h:609:43: sparse: sparse: bad integer constant expression include/linux/sched.h:609:73: sparse: sparse: invalid named zero-width bitfield `value' include/linux/sched.h:610:43: sparse: sparse: bad integer constant expression include/linux/sched.h:610:67: sparse: sparse: invalid named zero-width bitfield `bucket_id' net/vmw_vsock/hyperv_transport.c:214:39: sparse: sparse: undefined identifier 'HV_HYP_PAGE_SIZE' net/vmw_vsock/hyperv_transport.c:214:39: sparse: sparse: undefined identifier 'HV_HYP_PAGE_SIZE' >> net/vmw_vsock/hyperv_transport.c:214:39: sparse: sparse: incompatible types >> for operation (-) >> net/vmw_vsock/hyperv_transport.c:214:39: sparse:left side has type bad >> type >> net/vmw_vsock/hyperv_transport.c:214:39: sparse:right side has type int net/vmw_vsock/hyperv_transport.c:214:39: sparse: sparse: undefined identifier 'HV_HYP_PAGE_SIZE' >> net/vmw_vsock/hyperv_transport.c:214:39: sparse: sparse: incompatible types >> for operation (-) >> net/vmw_vsock/hyperv_transport.c:214:39: sparse:left side has type bad >> type >> net/vmw_vsock/hyperv_transport.c:214:39: sparse:right side has type int net/vmw_vsock/hyperv_transport.c:65:17: sparse: sparse: undefined identifier 'HV_HYP_PAGE_SIZE' >> net/vmw_vsock/hyperv_transport.c:65:17: sparse: sparse: bad constant >> expression type net/vmw_vsock/hyperv_transport.c:387:26: sparse: sparse: undefined identifier 'HV_HYP_PAGE_SIZE' net/vmw_vsock/hyperv_transport.c:388:26: sparse: sparse: undefined identifier 'HV_HYP_PAGE_SIZE' net/vmw_vsock/hyperv_transport.c:390:26: sparse: sparse: undefined identifier 'HV_HYP_PAGE_SIZE' >> net/vmw_vsock/hyperv_transport.c:390:26: sparse: sparse: cast from unknown >> type net/vmw_vsock/hyperv_transport.c:390:26: sparse: sparse: undefined identifier 'HV_HYP_PAGE_SIZE' >> net/vmw_vsock/hyperv_transport.c:390:26: sparse: sparse: cast from unknown >> type net/vmw_vsock/hyperv_transport.c:390:26: sparse: sparse: undefined identifier 'HV_HYP_PAGE_SIZE' >> net/vmw_vsock/hyperv_transport.c:390:26: sparse: sparse: cast from unknown >> type net/vmw_vsock/hyperv_transport.c:390:26: sparse: sparse: undefined identifier 'HV_HYP_PAGE_SIZE' >> net/vmw_vsock/hyperv_transport.c:390:26: sparse: sparse: cast from unknown >> type net/vmw_vsock/hyperv_transport.c:390:26: sparse: sparse: undefined identifier 'HV_HYP_PAGE_SIZE' >> net/vmw_vsock/hyperv_transport.c:390:26: sparse: sparse: cast from unknown >> type net/vmw_vsock/hyperv_transport.c:391:26: sparse: sparse: undefined identifier 'HV_HYP_PAGE_SIZE' net/vmw_vsock/hyperv_transport.c:391:26: sparse: sparse: cast from unknown type net/vmw_vsock/hyperv_transport.c:391:26: sparse: sparse: undefined identifier 'HV_HYP_PAGE_SIZE' net/vmw_vsock/hyperv_transport.c:391:26: sparse: sparse: cast from unknown type net/vmw_vsock/hyperv_transport.c:391:26: sparse: sparse: undefined identifier 'HV_HYP_PAGE_SIZE' net/vmw_vsock/hyperv_transport.c:391:26: sparse: sparse: cast from unknown type net/vmw_vsock/hyperv_transport.c:391:26: sparse: sparse: undefined identifier 'HV_HYP_PAGE_SIZE' net/vmw_vsock/hyperv_transport.c:391:26: sparse: sparse: cast from unknown type net/vmw_vsock/hyperv_transport.c:391:26: sparse: sparse: undefined identifier 'HV_HYP_PAGE_SIZE' net/vmw_vsock/hyperv_transport.c:391:26: sparse: sparse: cast from unknown type net/vmw_vsock/hyperv_transport.c:392:26: sparse: sparse: undefined identifier 'HV_HYP_PAGE_SIZE' net/vmw_vsock/hyperv_transport.c:392:26: sparse: sparse: cast from unknown type net/vmw_vsock/hyperv_transport.c:392:26: sparse: sparse: undefined identifier 'HV_HYP_PAGE_SIZE' net/vmw_vsock/hyperv_transport.c:392:26: sparse: sparse: cast from unknown type net/vmw_vsock/hyperv_transport.c:393:26: sparse: sparse: undefined identifier 'HV_HYP_PAGE_SIZE' net/vmw_vsock/hyperv_transport.c:393:26: sparse: sparse: cast from unknown type net/vmw_vsock/hyperv_transport.c:393:26: sparse: sparse: undefined identifier 'HV_HYP_PAGE_SIZE' net/vmw_vsock/hyperv_transport.c:393:26: sparse: sparse: cast from unknown type net/vmw_vsock/hyperv_transport.c:393:26: sparse: sparse: undefined identifier 'HV_HYP_PAGE_SIZE'
Re: [PATCH] sched/core: Don't use dying mm as active_mm for kernel threads
Hi Waiman, Thank you for the patch! Yet something to improve: [auto build test ERROR on linus/master] [cannot apply to v5.3-rc1 next-20190726] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Waiman-Long/sched-core-Don-t-use-dying-mm-as-active_mm-for-kernel-threads/20190728-101948 config: x86_64-randconfig-s1-07280001 (attached as .config) compiler: gcc-4.9 (Debian 4.9.2-10+deb8u1) 4.9.2 reproduce: # save the attached .config to linux build tree make ARCH=x86_64 If you fix the issue, kindly add following tag Reported-by: kbuild test robot All errors (new ones prefixed by >>): >> mm/init-mm.c:40:2: error: unknown field 'owner' specified in initializer .owner = _task, ^ mm/init-mm.c:40:2: warning: excess elements in struct initializer mm/init-mm.c:40:2: warning: (near initialization for 'init_mm') vim +/owner +40 mm/init-mm.c --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip
[PATCH v5 6/6] ARM: dts: sun8i: s3: add devicetree for Lichee zero plus w/ S3
Lichee zero plus is a core board made by Sipeed, which includes on-board
TF slot or SMT SD NAND, and optional SPI NOR or eMMC, a UART debug
header, a microUSB slot and a gold finger connector for expansion. It
can use either Sochip S3 or Allwinner S3L SoC.
Add the basic device tree for the core board, w/o optional onboard
storage, and with S3 SoC.
Signed-off-by: Icenowy Zheng
---
Changes in v5:
- Added missing compatible string.
- Set default USB role to "peripheral".
- Switch to use V3 DTSI.
No changes in v4.
Changes in v3:
- Drop common regulator DTSI usage and added vcc3v3 regulator.
Patch introduced in v2.
arch/arm/boot/dts/Makefile| 1 +
.../boot/dts/sun8i-s3-lichee-zero-plus.dts| 53 +++
2 files changed, 54 insertions(+)
create mode 100644 arch/arm/boot/dts/sun8i-s3-lichee-zero-plus.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index bef2b6e2392d..ef937988b30e 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -1120,6 +1120,7 @@ dtb-$(CONFIG_MACH_SUN8I) += \
sun8i-r16-nintendo-super-nes-classic.dtb \
sun8i-r16-parrot.dtb \
sun8i-r40-bananapi-m2-ultra.dtb \
+ sun8i-s3-lichee-zero-plus.dtb \
sun8i-t3-cqa3t-bv3.dtb \
sun8i-v3s-licheepi-zero.dtb \
sun8i-v3s-licheepi-zero-dock.dtb \
diff --git a/arch/arm/boot/dts/sun8i-s3-lichee-zero-plus.dts
b/arch/arm/boot/dts/sun8i-s3-lichee-zero-plus.dts
new file mode 100644
index ..d18192d51d1b
--- /dev/null
+++ b/arch/arm/boot/dts/sun8i-s3-lichee-zero-plus.dts
@@ -0,0 +1,53 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (C) 2019 Icenowy Zheng
+ */
+
+/dts-v1/;
+#include "sun8i-v3.dtsi"
+
+#include
+
+/ {
+ model = "Sipeed Lichee Zero Plus";
+ compatible = "sipeed,lichee-zero-plus", "sochip,s3",
+"allwinner,sun8i-v3";
+
+ aliases {
+ serial0 =
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ reg_vcc3v3: vcc3v3 {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc3v3";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ };
+};
+
+ {
+ broken-cd;
+ bus-width = <4>;
+ vmmc-supply = <_vcc3v3>;
+ status = "okay";
+};
+
+ {
+ pinctrl-0 = <_pb_pins>;
+ pinctrl-names = "default";
+ status = "okay";
+};
+
+_otg {
+ dr_mode = "peripheral";
+ status = "okay";
+};
+
+ {
+ usb0_id_det-gpios = < 5 6 GPIO_ACTIVE_HIGH>;
+ status = "okay";
+};
--
2.21.0
[PATCH v5 3/6] clk: sunxi-ng: v3s: add Allwinner V3 support
Allwinner V3 has the same main die with V3s, but with more pins wired.
There's a I2S bus on V3 that is not available on V3s.
Add the V3-only peripheral's clocks and reset to the V3s CCU driver,
bound to a new V3 compatible string. The driver name is not changed
because it's part of the device tree binding (the header file name).
Signed-off-by: Icenowy Zheng
---
Changes in v5:
- Fix MMC2 clock slices.
Changes in v4:
- Add the missing MMC2 clock slices.
No changes in v3/v2.
drivers/clk/sunxi-ng/ccu-sun8i-v3s.c | 228 +-
drivers/clk/sunxi-ng/ccu-sun8i-v3s.h | 2 +-
include/dt-bindings/clock/sun8i-v3s-ccu.h | 4 +
include/dt-bindings/reset/sun8i-v3s-ccu.h | 3 +
4 files changed, 234 insertions(+), 3 deletions(-)
diff --git a/drivers/clk/sunxi-ng/ccu-sun8i-v3s.c
b/drivers/clk/sunxi-ng/ccu-sun8i-v3s.c
index f79170e145df..5c779eec454b 100644
--- a/drivers/clk/sunxi-ng/ccu-sun8i-v3s.c
+++ b/drivers/clk/sunxi-ng/ccu-sun8i-v3s.c
@@ -235,6 +235,8 @@ static SUNXI_CCU_GATE(bus_codec_clk,"bus-codec",
"apb1",
0x068, BIT(0), 0);
static SUNXI_CCU_GATE(bus_pio_clk, "bus-pio", "apb1",
0x068, BIT(5), 0);
+static SUNXI_CCU_GATE(bus_i2s0_clk,"bus-i2s0", "apb1",
+ 0x068, BIT(12), 0);
static SUNXI_CCU_GATE(bus_i2c0_clk,"bus-i2c0", "apb2",
0x06c, BIT(0), 0);
@@ -306,6 +308,11 @@ static SUNXI_CCU_MP_WITH_MUX_GATE(spi0_clk, "spi0",
mod0_default_parents, 0x0a0,
BIT(31), /* gate */
0);
+static const char * const i2s_parents[] = { "pll-audio-8x", "pll-audio-4x",
+ "pll-audio-2x", "pll-audio" };
+static SUNXI_CCU_MUX_WITH_GATE(i2s0_clk, "i2s0", i2s_parents,
+ 0x0b0, 16, 2, BIT(31), CLK_SET_RATE_PARENT);
+
static SUNXI_CCU_GATE(usb_phy0_clk,"usb-phy0", "osc24M",
0x0cc, BIT(8), 0);
static SUNXI_CCU_GATE(usb_ohci0_clk, "usb-ohci0","osc24M",
@@ -443,6 +450,80 @@ static const struct clk_hw *clk_parent_pll_audio[] = {
_audio_base_clk.common.hw
};
+static struct ccu_common *sun8i_v3_ccu_clks[] = {
+ _cpu_clk.common,
+ _audio_base_clk.common,
+ _video_clk.common,
+ _ve_clk.common,
+ _ddr0_clk.common,
+ _periph0_clk.common,
+ _isp_clk.common,
+ _periph1_clk.common,
+ _ddr1_clk.common,
+ _clk.common,
+ _clk.common,
+ _clk.common,
+ _clk.common,
+ _clk.common,
+ _clk.common,
+ _ce_clk.common,
+ _dma_clk.common,
+ _mmc0_clk.common,
+ _mmc1_clk.common,
+ _mmc2_clk.common,
+ _dram_clk.common,
+ _emac_clk.common,
+ _hstimer_clk.common,
+ _spi0_clk.common,
+ _otg_clk.common,
+ _ehci0_clk.common,
+ _ohci0_clk.common,
+ _ve_clk.common,
+ _tcon0_clk.common,
+ _csi_clk.common,
+ _de_clk.common,
+ _codec_clk.common,
+ _pio_clk.common,
+ _i2s0_clk.common,
+ _i2c0_clk.common,
+ _i2c1_clk.common,
+ _uart0_clk.common,
+ _uart1_clk.common,
+ _uart2_clk.common,
+ _ephy_clk.common,
+ _dbg_clk.common,
+ _clk.common,
+ _sample_clk.common,
+ _output_clk.common,
+ _clk.common,
+ _sample_clk.common,
+ _output_clk.common,
+ _clk.common,
+ _sample_clk.common,
+ _output_clk.common,
+ _clk.common,
+ _clk.common,
+ _clk.common,
+ _phy0_clk.common,
+ _ohci0_clk.common,
+ _clk.common,
+ _ve_clk.common,
+ _csi_clk.common,
+ _ohci_clk.common,
+ _ehci_clk.common,
+ _clk.common,
+ _clk.common,
+ _misc_clk.common,
+ _mclk_clk.common,
+ _sclk_clk.common,
+ _mclk_clk.common,
+ _clk.common,
+ _dig_clk.common,
+ _clk.common,
+ _clk.common,
+ _csi_clk.common,
+};
+
/* We hardcode the divider to 4 for now */
static CLK_FIXED_FACTOR_HWS(pll_audio_clk, "pll-audio",
clk_parent_pll_audio,
@@ -540,6 +621,88 @@ static struct clk_hw_onecell_data sun8i_v3s_hw_clks = {
.num= CLK_NUMBER,
};
+static struct clk_hw_onecell_data sun8i_v3_hw_clks = {
+ .hws= {
+ [CLK_PLL_CPU] = _cpu_clk.common.hw,
+ [CLK_PLL_AUDIO_BASE]= _audio_base_clk.common.hw,
+ [CLK_PLL_AUDIO] = _audio_clk.hw,
+ [CLK_PLL_AUDIO_2X] = _audio_2x_clk.hw,
+ [CLK_PLL_AUDIO_4X] = _audio_4x_clk.hw,
+ [CLK_PLL_AUDIO_8X] = _audio_8x_clk.hw,
+ [CLK_PLL_VIDEO] = _video_clk.common.hw,
+ [CLK_PLL_VE]= _ve_clk.common.hw,
+ [CLK_PLL_DDR0] = _ddr0_clk.common.hw,
+ [CLK_PLL_PERIPH0] =
[PATCH v5 4/6] ARM: sunxi: dts: s3/s3l/v3: add DTSI files for S3/S3L/V3 SoCs
The Allwinner S3/S3L/V3 SoCs all share the same die with the V3s SoC,
but with more GPIO wired out of the package.
Add a DTSI file for these SoCs. It just replaces some compatible strings
of the V3s DTSI now. As these SoCs share the same feature set on Linux,
we use the first known chip (V3) as the file's name.
Signed-off-by: Icenowy Zheng
---
Changes in v5:
- Dropped dedicated S3/S3L DTSIs.
No changes until v5.
arch/arm/boot/dts/sun8i-v3.dtsi | 14 ++
1 file changed, 14 insertions(+)
create mode 100644 arch/arm/boot/dts/sun8i-v3.dtsi
diff --git a/arch/arm/boot/dts/sun8i-v3.dtsi b/arch/arm/boot/dts/sun8i-v3.dtsi
new file mode 100644
index ..6ae8645ade50
--- /dev/null
+++ b/arch/arm/boot/dts/sun8i-v3.dtsi
@@ -0,0 +1,14 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (C) 2019 Icenowy Zheng
+ */
+
+#include "sun8i-v3s.dtsi"
+
+ {
+ compatible = "allwinner,sun8i-v3-ccu";
+};
+
+ {
+ compatible = "allwinner,sun8i-v3-pinctrl";
+};
--
2.21.0
[PATCH v5 2/6] clk: sunxi-ng: v3s: add missing clock slices for MMC2 module clocks
The MMC2 clock slices are currently not defined in V3s CCU driver, which
makes MMC2 not working.
Fix this issue.
Fixes: d0f11d14b0bc ("clk: sunxi-ng: add support for V3s CCU")
Signed-off-by: Icenowy Zheng
---
Changes in v5:
- Fix typo on hw_clk reference.
Patch introduced in v4.
drivers/clk/sunxi-ng/ccu-sun8i-v3s.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/clk/sunxi-ng/ccu-sun8i-v3s.c
b/drivers/clk/sunxi-ng/ccu-sun8i-v3s.c
index 4eb68243e310..f79170e145df 100644
--- a/drivers/clk/sunxi-ng/ccu-sun8i-v3s.c
+++ b/drivers/clk/sunxi-ng/ccu-sun8i-v3s.c
@@ -513,6 +513,9 @@ static struct clk_hw_onecell_data sun8i_v3s_hw_clks = {
[CLK_MMC1] = _clk.common.hw,
[CLK_MMC1_SAMPLE] = _sample_clk.common.hw,
[CLK_MMC1_OUTPUT] = _output_clk.common.hw,
+ [CLK_MMC2] = _clk.common.hw,
+ [CLK_MMC2_SAMPLE] = _sample_clk.common.hw,
+ [CLK_MMC2_OUTPUT] = _output_clk.common.hw,
[CLK_CE]= _clk.common.hw,
[CLK_SPI0] = _clk.common.hw,
[CLK_USB_PHY0] = _phy0_clk.common.hw,
--
2.21.0
[PATCH v5 1/6] pinctrl: sunxi: v3s: introduce support for V3
Introduce the GPIO pins that is only available on V3 (not on V3s) to the
V3s pinctrl driver.
Signed-off-by: Icenowy Zheng
Acked-by: Maxime Ripard
---
No changes in v5.
Changes in v4:
- Removed bogus alignment change.
Changes in v3:
- Fixed code alignment.
- Fixed LVDS function number.
Changes in v2:
- Dropped the driver rename patch and apply the changes directly on V3s
driver.
drivers/pinctrl/sunxi/pinctrl-sun8i-v3s.c | 265 +-
drivers/pinctrl/sunxi/pinctrl-sunxi.h | 2 +
2 files changed, 262 insertions(+), 5 deletions(-)
diff --git a/drivers/pinctrl/sunxi/pinctrl-sun8i-v3s.c
b/drivers/pinctrl/sunxi/pinctrl-sun8i-v3s.c
index 6704ce8e5e3d..ca85438e379a 100644
--- a/drivers/pinctrl/sunxi/pinctrl-sun8i-v3s.c
+++ b/drivers/pinctrl/sunxi/pinctrl-sun8i-v3s.c
@@ -1,5 +1,5 @@
/*
- * Allwinner V3s SoCs pinctrl driver.
+ * Allwinner V3/V3s SoCs pinctrl driver.
*
* Copyright (C) 2016 Icenowy Zheng
*
@@ -77,6 +77,30 @@ static const struct sunxi_desc_pin sun8i_v3s_pins[] = {
SUNXI_FUNCTION(0x2, "i2c1"), /* SCK */
SUNXI_FUNCTION(0x3, "uart0"), /* RX */
SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 9)), /* PB_EINT9 */
+ SUNXI_PIN_VARIANT(SUNXI_PINCTRL_PIN(B, 10),
+ PINCTRL_SUN8I_V3,
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out"),
+ SUNXI_FUNCTION(0x2, "jtag"), /* MS */
+ SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 10)), /* PB_EINT10 */
+ SUNXI_PIN_VARIANT(SUNXI_PINCTRL_PIN(B, 11),
+ PINCTRL_SUN8I_V3,
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out"),
+ SUNXI_FUNCTION(0x2, "jtag"), /* CK */
+ SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 11)), /* PB_EINT11 */
+ SUNXI_PIN_VARIANT(SUNXI_PINCTRL_PIN(B, 12),
+ PINCTRL_SUN8I_V3,
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out"),
+ SUNXI_FUNCTION(0x2, "jtag"), /* DO */
+ SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 12)), /* PB_EINT12 */
+ SUNXI_PIN_VARIANT(SUNXI_PINCTRL_PIN(B, 13),
+ PINCTRL_SUN8I_V3,
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out"),
+ SUNXI_FUNCTION(0x2, "jtag"), /* DI */
+ SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 13)), /* PB_EINT13 */
/* Hole */
SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 0),
SUNXI_FUNCTION(0x0, "gpio_in"),
@@ -98,6 +122,180 @@ static const struct sunxi_desc_pin sun8i_v3s_pins[] = {
SUNXI_FUNCTION(0x1, "gpio_out"),
SUNXI_FUNCTION(0x2, "mmc2"), /* D0 */
SUNXI_FUNCTION(0x3, "spi0")), /* MOSI */
+ SUNXI_PIN_VARIANT(SUNXI_PINCTRL_PIN(C, 4),
+ PINCTRL_SUN8I_V3,
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out"),
+ SUNXI_FUNCTION(0x2, "mmc2")), /* D1 */
+ SUNXI_PIN_VARIANT(SUNXI_PINCTRL_PIN(C, 5),
+ PINCTRL_SUN8I_V3,
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out"),
+ SUNXI_FUNCTION(0x2, "mmc2")), /* D2 */
+ SUNXI_PIN_VARIANT(SUNXI_PINCTRL_PIN(C, 6),
+ PINCTRL_SUN8I_V3,
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out"),
+ SUNXI_FUNCTION(0x2, "mmc2")), /* D3 */
+ SUNXI_PIN_VARIANT(SUNXI_PINCTRL_PIN(C, 7),
+ PINCTRL_SUN8I_V3,
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out"),
+ SUNXI_FUNCTION(0x2, "mmc2")), /* D4 */
+ SUNXI_PIN_VARIANT(SUNXI_PINCTRL_PIN(C, 8),
+ PINCTRL_SUN8I_V3,
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out"),
+ SUNXI_FUNCTION(0x2, "mmc2")), /* D5 */
+ SUNXI_PIN_VARIANT(SUNXI_PINCTRL_PIN(C, 9),
+ PINCTRL_SUN8I_V3,
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out"),
+ SUNXI_FUNCTION(0x2, "mmc2")), /* D6 */
+ SUNXI_PIN_VARIANT(SUNXI_PINCTRL_PIN(C, 10),
+ PINCTRL_SUN8I_V3,
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out"),
+
[PATCH v5 5/6] dt-bindings: arm: sunxi: add binding for Lichee Zero Plus core board
The Lichee Zero Plus is a core board made by Sipeed, with a microUSB connector on it, TF slot or WSON8 SD chip, optional eMMC or SPI Flash. It has a gold finger connector for expansion, and UART is available from reserved pins w/ 2.54mm pitch. The board can use either SoChip S3 or Allwinner V3L SoCs. Add the device tree binding of the basic version of the core board -- w/o eMMC or SPI Flash, w/ TF slot or WSON8 SD, and use S3 SoC. Signed-off-by: Icenowy Zheng Reviewed-by: Rob Herring --- Changes in v5: - Added V3 compatible to S3 board. - Fixed S3 compatible string. No changes until v5. Patch introduced in v2. Documentation/devicetree/bindings/arm/sunxi.yaml | 6 ++ 1 file changed, 6 insertions(+) diff --git a/Documentation/devicetree/bindings/arm/sunxi.yaml b/Documentation/devicetree/bindings/arm/sunxi.yaml index 000a00d12d6a..f6fc68ad 100644 --- a/Documentation/devicetree/bindings/arm/sunxi.yaml +++ b/Documentation/devicetree/bindings/arm/sunxi.yaml @@ -353,6 +353,12 @@ properties: - const: licheepi,licheepi-zero - const: allwinner,sun8i-v3s + - description: Lichee Zero Plus (with S3, without eMMC/SPI Flash) +items: + - const: sipeed,lichee-zero-plus + - const: sochip,s3 + - const: allwinner,sun8i-v3 + - description: Linksprite PCDuino items: - const: linksprite,a10-pcduino -- 2.21.0
[PATCH v5 0/6] Support for Allwinner V3/S3L and Sochip S3
This patchset tries to add support for Allwinner V3/S3L and Sochip S3. Allwinner V3/V3s/S3L and Sochip S3 share the same die, but with different package. V3 is BGA w/o co-packaged DDR, V3s is QFP w/ DDR2, S3L is BGA w/ DDR2 and S3 is BGA w/ DDR3. (S3 and S3L is compatible for pinout, but because of different DDR, DDR voltage is different between the two variants). Because of the pin count of V3s is restricted due to the package, some pins are not bound on V3s, but they're bound on V3/S3/S3L. Currently the kernel is only prepared for the features available on V3s. This patchset adds the features missing on V3s for using them on V3/S3/S3L, and add bindings for V3/S3/S3L. It also adds a S3 SoM by Sipeed, called Lichee Zero Plus. Icenowy Zheng (6): pinctrl: sunxi: v3s: introduce support for V3 clk: sunxi-ng: v3s: add missing clock slices for MMC2 module clocks clk: sunxi-ng: v3s: add Allwinner V3 support ARM: sunxi: dts: s3/s3l/v3: add DTSI files for S3/S3L/V3 SoCs dt-bindings: arm: sunxi: add binding for Lichee Zero Plus core board ARM: dts: sun8i: s3: add devicetree for Lichee zero plus w/ S3 .../devicetree/bindings/arm/sunxi.yaml| 6 + arch/arm/boot/dts/Makefile| 1 + .../boot/dts/sun8i-s3-lichee-zero-plus.dts| 53 arch/arm/boot/dts/sun8i-v3.dtsi | 14 + drivers/clk/sunxi-ng/ccu-sun8i-v3s.c | 231 ++- drivers/clk/sunxi-ng/ccu-sun8i-v3s.h | 2 +- drivers/pinctrl/sunxi/pinctrl-sun8i-v3s.c | 265 +- drivers/pinctrl/sunxi/pinctrl-sunxi.h | 2 + include/dt-bindings/clock/sun8i-v3s-ccu.h | 4 + include/dt-bindings/reset/sun8i-v3s-ccu.h | 3 + 10 files changed, 573 insertions(+), 8 deletions(-) create mode 100644 arch/arm/boot/dts/sun8i-s3-lichee-zero-plus.dts create mode 100644 arch/arm/boot/dts/sun8i-v3.dtsi -- 2.21.0
[PATCH v2] lkmm/docs: Correct ->prop example with additional rfe link
The lkmm example about ->prop relation should describe an additional rfe link between P1's store to y and P2's load of y, which should be critical to establishing the ordering resulting in the ->prop ordering on P0. IOW, there are 2 rfe links, not one. Correct these in the docs to make the ->prop ordering on P0 more clear. Cc: kernel-t...@android.com Reviewed-by: Boqun Feng Signed-off-by: Joel Fernandes (Google) --- .../memory-model/Documentation/explanation.txt | 17 ++--- 1 file changed, 10 insertions(+), 7 deletions(-) diff --git a/tools/memory-model/Documentation/explanation.txt b/tools/memory-model/Documentation/explanation.txt index 68caa9a976d0..aa84fce854cc 100644 --- a/tools/memory-model/Documentation/explanation.txt +++ b/tools/memory-model/Documentation/explanation.txt @@ -1302,8 +1302,8 @@ followed by an arbitrary number of cumul-fence links, ending with an rfe link. You can concoct more exotic examples, containing more than one fence, although this quickly leads to diminishing returns in terms of complexity. For instance, here's an example containing a coe link -followed by two fences and an rfe link, utilizing the fact that -release fences are A-cumulative: +followed by a fence, an rfe link, another fence and and a final rfe link, +utilizing the fact that release fences are A-cumulative: int x, y, z; @@ -1334,11 +1334,14 @@ If x = 2, r0 = 1, and r2 = 1 after this code runs then there is a prop link from P0's store to its load. This is because P0's store gets overwritten by P1's store since x = 2 at the end (a coe link), the smp_wmb() ensures that P1's store to x propagates to P2 before the -store to y does (the first fence), the store to y propagates to P2 -before P2's load and store execute, P2's smp_store_release() -guarantees that the stores to x and y both propagate to P0 before the -store to z does (the second fence), and P0's load executes after the -store to z has propagated to P0 (an rfe link). +store to y does (the first fence), P2's store to y happens before P2's +load of y (rfe link), P2's smp_store_release() ensures that P2's load +of y executes before P2's store to z (second fence), which implies that +that stores to x and y propagate to P2 before the smp_store_release(), which +means that P2's smp_store_release() will propagate stores to x and y to all +CPUs before the store to z propagates (A-cumulative property of this fence). +Finally P0's load of z executes after P2's store to z has propagated to +P0 (rfe link). In summary, the fact that the hb relation links memory access events in the order they execute means that it must not have cycles. This -- 2.22.0.709.g102302147b-goog
Re: [PATCH 09/16] sparc64: use the generic get_user_pages_fast code
From: Anatoly Pugachev Date: Thu, 25 Jul 2019 21:33:24 +0300 > http://u164.east.ru/kernel/ > > there's vmlinuz-5.3.0-rc1 kernel and archive 5.3.0-rc1-modules.tar.gz > of /lib/modules/5.3.0-rc1/ > this is from oracle sparclinux LDOM , compiled with 7.4.0 gcc Please, I really really need the unstripped kernel image with all the symbols. This vmlinuz file is stripped already. The System.map does not serve as a replacement. Thank you.
Re: [PATCH] docs/lkmm: Correct ->prop example with additional rfe link
Hi Joel, On Sat, Jul 27, 2019 at 08:00:31PM -0400, Joel Fernandes (Google) wrote: > This lkmm example should describe an additional rfe link between P1's > store to y and P2's load of y, which should be critical to establishing > the ordering resulting in the ->prop ordering on P0. IOW, there are 2 rfe > links, not one. > > Correct these in the docs to make the ->prop ordering in P0 more clear. > > Signed-off-by: Joel Fernandes (Google) > --- > tools/memory-model/Documentation/explanation.txt | 16 +--- > 1 file changed, 9 insertions(+), 7 deletions(-) > > diff --git a/tools/memory-model/Documentation/explanation.txt > b/tools/memory-model/Documentation/explanation.txt > index 68caa9a976d0..6c0dfaac7f04 100644 > --- a/tools/memory-model/Documentation/explanation.txt > +++ b/tools/memory-model/Documentation/explanation.txt > @@ -1302,8 +1302,8 @@ followed by an arbitrary number of cumul-fence links, > ending with an > rfe link. You can concoct more exotic examples, containing more than > one fence, although this quickly leads to diminishing returns in terms > of complexity. For instance, here's an example containing a coe link > -followed by two fences and an rfe link, utilizing the fact that > -release fences are A-cumulative: > +followed by a fence, an rfe link, another fence and and a final rfe link, > +utilizing the fact that release fences are A-cumulative: > This part looks good to me. > int x, y, z; > > @@ -1334,11 +1334,13 @@ If x = 2, r0 = 1, and r2 = 1 after this code runs > then there is a prop > link from P0's store to its load. This is because P0's store gets > overwritten by P1's store since x = 2 at the end (a coe link), the > smp_wmb() ensures that P1's store to x propagates to P2 before the > -store to y does (the first fence), the store to y propagates to P2 > -before P2's load and store execute, P2's smp_store_release() > -guarantees that the stores to x and y both propagate to P0 before the > -store to z does (the second fence), and P0's load executes after the > -store to z has propagated to P0 (an rfe link). > +store to y does (the first fence), P2's store to y happens before P2's > +load of y (rfe link), P2's smp_store_release() ensures that P2's load > +of y executes before P2's store of z (second fence), which also would > +imply that stores to x and y happen before the smp_store_release(), which I think it's more accurate to say: "imply that stores to x and y progagates to P2 before the smp_store_release()" , because by definition the propagation ordering that smp_store_release() guarantees only works with stores that already propagated to the CPU executing it, not the stores that execute/happen before. With that, feel free to add: Reviewed-by: Boqun Feng Regards, Boqun > +means that P2's smp_store_release() will propagate stores to x and y to all > +CPUs before the store to z does (A-cumulative property of this fence). > +Finally P0's load executes after store to z has propagated to P0 (rfe link). > > In summary, the fact that the hb relation links memory access events > in the order they execute means that it must not have cycles. This > -- > 2.22.0.709.g102302147b-goog > signature.asc Description: PGP signature
Re: [PATCH V3 net-next 06/10] net: hns3: add debug messages to identify eth down cause
From: Huazhong Tan Date: Sat, 27 Jul 2019 13:46:08 +0800 > From: Yonglong Liu > > Some times just see the eth interface have been down/up via > dmesg, but can not know why the eth down. So adds some debug > messages to identify the cause for this. > > Signed-off-by: Yonglong Liu > Signed-off-by: Peng Li > Signed-off-by: Huazhong Tan > --- > drivers/net/ethernet/hisilicon/hns3/hns3_enet.c | 18 ++ > drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c| 19 > +++ > .../net/ethernet/hisilicon/hns3/hns3pf/hclge_dcb.c| 11 +++ > 3 files changed, 48 insertions(+) > > diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c > b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c > index 4d58c53..973c57b 100644 > --- a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c > +++ b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c > @@ -459,6 +459,9 @@ static int hns3_nic_net_open(struct net_device *netdev) > h->ae_algo->ops->set_timer_task(priv->ae_handle, true); > > hns3_config_xps(priv); > + > + netif_info(h, drv, netdev, "net open\n"); These will pollute everyone's kernel logs for normal operations. This is not reasonable at all, sorry. Furthermore, even if it was appropriate, "netif_info()" is not "debug".
Re: [RFC PATCH] modpost: check for static EXPORT_SYMBOL* functions
Hi. On Sun, Jul 28, 2019 at 4:14 AM Denis Efremov wrote: > > Hi. > > > Could you drop the solved ones from the list? > > Yes, of course. Do you want me to remove all symbols fixed with patches > or only those are in-tree now? > > Should it be like this: > 1. "torture_onoff_cleanup" [kernel/torture] > "torture_shuffle_cleanup" [kernel/torture] > Patch: https://lkml.org/lkml/2019/7/4/411 (accepted) > 2. "LZ4HC_setExternalDict" [lib/lz4/lz4hc_compress] > Patch: https://lkml.org/lkml/2019/7/8/842 > 3. "drm_client_close" [drivers/gpu/drm/drm] > Patch: https://lkml.org/lkml/2019/7/3/758 (accepted) > 4. "ahci_em_messages" [drivers/ata/libahci] > Patch: https://lkml.org/lkml/2019/7/10/550 (reviewed) > 5. "ftrace_set_clr_event" [vmlinux] > Patch: https://lkml.org/lkml/2019/7/4/609 (reviewed) > 6. "rmi_2d_sensor_set_input_params" [drivers/input/rmi4/rmi_core] > Patch: https://lkml.org/lkml/2019/7/8/999 (accepted) > 10. "empty_zero_page" [vmlinux] > 11. "phys_base" [vmlinux] > 12. "hypercall_page" [vmlinux] > > Or like this: > 1. "empty_zero_page" [vmlinux] > 2. "phys_base" [vmlinux] > 3. "hypercall_page" [vmlinux] > > Well, I could remove this list at all. It seems like the following list > with existing commits is enough to show the problem of static exported > functions. Yeah, I agree. Showing some existing commits is enough. > I will resend the patch shortly after. > > Regards, > Denis -- Best Regards Masahiro Yamada
Re: [PATCH net-next] mvpp2: document HW checksum behaviour
On Fri, Jul 26, 2019 at 2:57 PM Antoine Tenart
wrote:
>
> Hi Matteo,
>
> On Fri, Jul 26, 2019 at 01:15:46AM +0200, Matteo Croce wrote:
> > The hardware can only offload checksum calculation on first port due to
> > the Tx FIFO size limitation. Document this in a comment.
> >
> > Fixes: 576193f2d579 ("net: mvpp2: jumbo frames support")
> > Signed-off-by: Matteo Croce
>
> Looks good. Please note there's a similar code path in the probe. You
> could also add a comment there (or move this check/comment in a common
> place).
>
> Thanks!
> Antoine
>
Hi Antoine,
I was making a v2, when I looked at the mvpp2_port_probe() which does:
%<--
features = NETIF_F_SG | NETIF_F_IP_CSUM | NETIF_F_IPV6_CSUM | NETIF_F_TSO;
if (port->pool_long->id == MVPP2_BM_JUMBO && port->id != 0) {
dev->features &= ~(NETIF_F_IP_CSUM | NETIF_F_IPV6_CSUM);
dev->hw_features &= ~(NETIF_F_IP_CSUM | NETIF_F_IPV6_CSUM);
}
dev->vlan_features |= features;
>%--
Is it ok to remove NETIF_F_IP*_CSUM from dev->features and
dev->hw_features but keep it in dev->vlan_features?
Regards,
--
Matteo Croce
per aspera ad upstream
[PATCH net v2] mvpp2: refactor MTU change code
The MTU change code can call napi_disable() with the device already down,
leading to a deadlock. Also, lot of code is duplicated unnecessarily.
Rework mvpp2_change_mtu() to avoid the deadlock and remove duplicated code.
Fixes: 3f518509dedc ("ethernet: Add new driver for Marvell Armada 375 network
unit")
Signed-off-by: Matteo Croce
---
.../net/ethernet/marvell/mvpp2/mvpp2_main.c | 41 ++-
1 file changed, 13 insertions(+), 28 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
index b6591ea0c6d6..68fa2d563f0d 100644
--- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
+++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
@@ -3700,6 +3700,7 @@ static int mvpp2_set_mac_address(struct net_device *dev,
void *p)
static int mvpp2_change_mtu(struct net_device *dev, int mtu)
{
struct mvpp2_port *port = netdev_priv(dev);
+ bool running = netif_running(dev);
int err;
if (!IS_ALIGNED(MVPP2_RX_PKT_SIZE(mtu), 8)) {
@@ -3708,40 +3709,24 @@ static int mvpp2_change_mtu(struct net_device *dev, int
mtu)
mtu = ALIGN(MVPP2_RX_PKT_SIZE(mtu), 8);
}
- if (!netif_running(dev)) {
- err = mvpp2_bm_update_mtu(dev, mtu);
- if (!err) {
- port->pkt_size = MVPP2_RX_PKT_SIZE(mtu);
- return 0;
- }
-
- /* Reconfigure BM to the original MTU */
- err = mvpp2_bm_update_mtu(dev, dev->mtu);
- if (err)
- goto log_error;
- }
-
- mvpp2_stop_dev(port);
+ if (running)
+ mvpp2_stop_dev(port);
err = mvpp2_bm_update_mtu(dev, mtu);
- if (!err) {
+ if (err) {
+ netdev_err(dev, "failed to change MTU\n");
+ /* Reconfigure BM to the original MTU */
+ mvpp2_bm_update_mtu(dev, dev->mtu);
+ } else {
port->pkt_size = MVPP2_RX_PKT_SIZE(mtu);
- goto out_start;
}
- /* Reconfigure BM to the original MTU */
- err = mvpp2_bm_update_mtu(dev, dev->mtu);
- if (err)
- goto log_error;
-
-out_start:
- mvpp2_start_dev(port);
- mvpp2_egress_enable(port);
- mvpp2_ingress_enable(port);
+ if (running) {
+ mvpp2_start_dev(port);
+ mvpp2_egress_enable(port);
+ mvpp2_ingress_enable(port);
+ }
- return 0;
-log_error:
- netdev_err(dev, "failed to change MTU\n");
return err;
}
--
2.21.0
Re: [5.2 REGRESSION] Generic vDSO breaks seccomp-enabled userspace on i386
On Sat, Jul 27, 2019 at 2:52 PM Thomas Gleixner wrote:
>
> On Sat, 27 Jul 2019, Thomas Gleixner wrote:
> > On Sat, 27 Jul 2019, Andy Lutomirski wrote:
> > >
> > > I think it's getting quite late to start inventing new seccomp
> > > features to fix this. I think the right solution for 5.3 is to change
> > > the 32-bit vdso fallback to use the old clock_gettime, i.e.
> > > clock_gettime32. This is obviously not an acceptable long-term
> > > solution.
> >
> > Sigh. I'll have a look
>
> Completely untested patch below.
>
> For the record: I have to say that I hate it.
Me too.
How about something more like the attached. (The attachment obviously
won't compile, since it's incomplete. I'm wondering if you think the
idea is okay. The idea is to have the vdso calls fall back to the
corresponding syscalls rather than internally converting.)
--Andy
diff --git a/lib/vdso/gettimeofday.c b/lib/vdso/gettimeofday.c
index 2d1c1f241fd9..b7284330018d 100644
--- a/lib/vdso/gettimeofday.c
+++ b/lib/vdso/gettimeofday.c
@@ -51,7 +51,7 @@ static int do_hres(const struct vdso_data *vd, clockid_t clk,
ns = vdso_ts->nsec;
last = vd->cycle_last;
if (unlikely((s64)cycles < 0))
- return clock_gettime_fallback(clk, ts);
+ return -1;
ns += vdso_calc_delta(cycles, last, vd->mask, vd->mult);
ns >>= vd->shift;
@@ -86,6 +86,7 @@ __cvdso_clock_gettime(clockid_t clock, struct __kernel_timespec *ts)
{
const struct vdso_data *vd = __arch_get_vdso_data();
u32 msk;
+ int ret;
/* Check for negative values or invalid clocks */
if (unlikely((u32) clock >= MAX_CLOCKS))
@@ -97,14 +98,17 @@ __cvdso_clock_gettime(clockid_t clock, struct __kernel_timespec *ts)
*/
msk = 1U << clock;
if (likely(msk & VDSO_HRES)) {
- return do_hres([CS_HRES_COARSE], clock, ts);
+ ret = do_hres([CS_HRES_COARSE], clock, ts);
} else if (msk & VDSO_COARSE) {
do_coarse([CS_HRES_COARSE], clock, ts);
return 0;
} else if (msk & VDSO_RAW) {
- return do_hres([CS_RAW], clock, ts);
+ ret = do_hres([CS_RAW], clock, ts);
}
+ if (likely(ret == 0))
+ return clock_gettime_fallback(clock, ts);
+
fallback:
return clock_gettime_fallback(clock, ts);
}
@@ -120,15 +124,14 @@ __cvdso_clock_gettime32(clockid_t clock, struct old_timespec32 *res)
ret = __cvdso_clock_gettime(clock, );
- if (ret == 0) {
+ if (likely(ret == 0)) {
res->tv_sec = ts.tv_sec;
res->tv_nsec = ts.tv_nsec;
+ return ret;
}
- return ret;
-
fallback:
- return clock_gettime_fallback(clock, (struct __kernel_timespec *)res);
+ return clock_gettime32_fallback(clock, (struct __kernel_timespec *)res);
}
static __maybe_unused int
Re: [PATCH] rocker: fix memory leaks of fib_work on two error return paths
On 7/27/19 5:37 PM, Colin King wrote:
> From: Colin Ian King
>
> Currently there are two error return paths that leak memory allocated
> to fib_work. Fix this by kfree'ing fib_work before returning.
>
> Addresses-Coverity: ("Resource leak")
> Fixes: 19a9d136f198 ("ipv4: Flag fib_info with a fib_nh using IPv6 gateway")
> Fixes: dbcc4fa718ee ("rocker: Fail attempts to use routes with nexthop
> objects")
> Signed-off-by: Colin Ian King
> ---
> drivers/net/ethernet/rocker/rocker_main.c | 2 ++
> 1 file changed, 2 insertions(+)
>
Thanks for the patch,
Reviewed-by: David Ahern
[PATCH] docs/lkmm: Correct ->prop example with additional rfe link
This lkmm example should describe an additional rfe link between P1's store to y and P2's load of y, which should be critical to establishing the ordering resulting in the ->prop ordering on P0. IOW, there are 2 rfe links, not one. Correct these in the docs to make the ->prop ordering in P0 more clear. Signed-off-by: Joel Fernandes (Google) --- tools/memory-model/Documentation/explanation.txt | 16 +--- 1 file changed, 9 insertions(+), 7 deletions(-) diff --git a/tools/memory-model/Documentation/explanation.txt b/tools/memory-model/Documentation/explanation.txt index 68caa9a976d0..6c0dfaac7f04 100644 --- a/tools/memory-model/Documentation/explanation.txt +++ b/tools/memory-model/Documentation/explanation.txt @@ -1302,8 +1302,8 @@ followed by an arbitrary number of cumul-fence links, ending with an rfe link. You can concoct more exotic examples, containing more than one fence, although this quickly leads to diminishing returns in terms of complexity. For instance, here's an example containing a coe link -followed by two fences and an rfe link, utilizing the fact that -release fences are A-cumulative: +followed by a fence, an rfe link, another fence and and a final rfe link, +utilizing the fact that release fences are A-cumulative: int x, y, z; @@ -1334,11 +1334,13 @@ If x = 2, r0 = 1, and r2 = 1 after this code runs then there is a prop link from P0's store to its load. This is because P0's store gets overwritten by P1's store since x = 2 at the end (a coe link), the smp_wmb() ensures that P1's store to x propagates to P2 before the -store to y does (the first fence), the store to y propagates to P2 -before P2's load and store execute, P2's smp_store_release() -guarantees that the stores to x and y both propagate to P0 before the -store to z does (the second fence), and P0's load executes after the -store to z has propagated to P0 (an rfe link). +store to y does (the first fence), P2's store to y happens before P2's +load of y (rfe link), P2's smp_store_release() ensures that P2's load +of y executes before P2's store of z (second fence), which also would +imply that stores to x and y happen before the smp_store_release(), which +means that P2's smp_store_release() will propagate stores to x and y to all +CPUs before the store to z does (A-cumulative property of this fence). +Finally P0's load executes after store to z has propagated to P0 (rfe link). In summary, the fact that the hb relation links memory access events in the order they execute means that it must not have cycles. This -- 2.22.0.709.g102302147b-goog
[PATCH] rocker: fix memory leaks of fib_work on two error return paths
From: Colin Ian King
Currently there are two error return paths that leak memory allocated
to fib_work. Fix this by kfree'ing fib_work before returning.
Addresses-Coverity: ("Resource leak")
Fixes: 19a9d136f198 ("ipv4: Flag fib_info with a fib_nh using IPv6 gateway")
Fixes: dbcc4fa718ee ("rocker: Fail attempts to use routes with nexthop objects")
Signed-off-by: Colin Ian King
---
drivers/net/ethernet/rocker/rocker_main.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/ethernet/rocker/rocker_main.c
b/drivers/net/ethernet/rocker/rocker_main.c
index 079f459c73a5..2c5d3f5b84dd 100644
--- a/drivers/net/ethernet/rocker/rocker_main.c
+++ b/drivers/net/ethernet/rocker/rocker_main.c
@@ -2208,10 +2208,12 @@ static int rocker_router_fib_event(struct
notifier_block *nb,
if (fen_info->fi->fib_nh_is_v6) {
NL_SET_ERR_MSG_MOD(info->extack, "IPv6 gateway
with IPv4 route is not supported");
+ kfree(fib_work);
return notifier_from_errno(-EINVAL);
}
if (fen_info->fi->nh) {
NL_SET_ERR_MSG_MOD(info->extack, "IPv4 route
with nexthop objects is not supported");
+ kfree(fib_work);
return notifier_from_errno(-EINVAL);
}
}
--
2.20.1
[GIT pull] perf/urgent for 5.3-rc2
Linus,
please pull the latest perf-urgent-for-linus git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
perf-urgent-for-linus
up to: 289a2d22b5b6: perf/x86/intel: Mark expected switch fall-throughs
A pile of perf related fixes:
Kernel:
- Fix SLOTS PEBS event constraints for Icelake CPUs
- Add the missing mask bit to allow counting hardware generated
prefetches on L3 for Icelake CPUs
- Make the test for hypervisor platforms more accurate (as far as possible)
- Handle PMUs correctly which override event->cpu
- Yet another missing fallthrough annotation
Tools:
perf.data:
- Fix loading of compressed data split across adjacent records
- Fix buffer size setting for processing CPU topology perf.data header.
perf stat:
- Fix segfault for event group in repeat mode
- Always separate "stalled cycles per insn" line, it was being appended
to
the "instructions" line.
perf script:
- Fix --max-blocks man page description.
- Improve man page description of metrics.
- Fix off by one in brstackinsn IPC computation.
perf probe:
- Avoid calling freeing routine multiple times for same pointer.
perf build:
- Do not use -Wshadow on gcc < 4.8, avoiding too strict warnings
treated as errors, breaking the build.
Thanks,
tglx
-->
Alexey Budankov (1):
perf session: Fix loading of compressed data split across adjacent records
Andi Kleen (3):
perf script: Fix --max-blocks man page description
perf script: Improve man page description of metrics
perf script: Fix off by one in brstackinsn IPC computation
Arnaldo Carvalho de Melo (3):
perf probe: Set pev->nargs to zero after freeing pev->args entries
perf probe: Avoid calling freeing routine multiple times for same pointer
perf build: Do not use -Wshadow on gcc < 4.8
Cong Wang (1):
perf stat: Always separate stalled cycles per insn
Gustavo A. R. Silva (1):
perf/x86/intel: Mark expected switch fall-throughs
Jiri Olsa (2):
perf tools: Fix proper buffer size for feature processing
perf stat: Fix segfault for event group in repeat mode
Kan Liang (1):
perf/x86/intel: Fix SLOTS PEBS event constraint
Leonard Crestez (1):
perf/core: Fix creating kernel counters for PMUs that override event->cpu
Yunying Sun (1):
perf/x86/intel: Fix invalid Bit 13 for Icelake MSR_OFFCORE_RSP_x register
Zhenzhong Duan (1):
perf/x86: Apply more accurate check on hypervisor platform
arch/x86/events/intel/core.c | 9 +
arch/x86/events/intel/ds.c | 2 +-
kernel/events/core.c | 2 +-
tools/perf/Documentation/perf-script.txt | 8
tools/perf/builtin-probe.c | 10 ++
tools/perf/builtin-script.c | 2 +-
tools/perf/builtin-stat.c| 9 -
tools/perf/util/evsel.c | 2 ++
tools/perf/util/header.c | 2 +-
tools/perf/util/probe-event.c| 1 +
tools/perf/util/session.c| 22 ++
tools/perf/util/session.h| 1 +
tools/perf/util/stat-shadow.c| 3 ++-
tools/perf/util/zstd.c | 4 ++--
tools/scripts/Makefile.include | 9 -
15 files changed, 61 insertions(+), 25 deletions(-)
diff --git a/arch/x86/events/intel/core.c b/arch/x86/events/intel/core.c
index 9e911a96972b..648260b5f367 100644
--- a/arch/x86/events/intel/core.c
+++ b/arch/x86/events/intel/core.c
@@ -20,7 +20,6 @@
#include
#include
#include
-#include
#include "../perf_event.h"
@@ -263,8 +262,8 @@ static struct event_constraint
intel_icl_event_constraints[] = {
};
static struct extra_reg intel_icl_extra_regs[] __read_mostly = {
- INTEL_UEVENT_EXTRA_REG(0x01b7, MSR_OFFCORE_RSP_0, 0x3f9fffull,
RSP_0),
- INTEL_UEVENT_EXTRA_REG(0x01bb, MSR_OFFCORE_RSP_1, 0x3f9fffull,
RSP_1),
+ INTEL_UEVENT_EXTRA_REG(0x01b7, MSR_OFFCORE_RSP_0, 0x3fbfffull,
RSP_0),
+ INTEL_UEVENT_EXTRA_REG(0x01bb, MSR_OFFCORE_RSP_1, 0x3fbfffull,
RSP_1),
INTEL_UEVENT_PEBS_LDLAT_EXTRA_REG(0x01cd),
INTEL_UEVENT_EXTRA_REG(0x01c6, MSR_PEBS_FRONTEND, 0x7fff17, FE),
EVENT_EXTRA_END
@@ -4053,7 +4052,7 @@ static bool check_msr(unsigned long msr, u64 mask)
* Disable the check for real HW, so we don't
* mess with potentionaly enabled registers:
*/
- if (hypervisor_is_type(X86_HYPER_NATIVE))
+ if (!boot_cpu_has(X86_FEATURE_HYPERVISOR))
return true;
/*
@@ -4955,6 +4954,7 @@ __init int intel_pmu_init(void)
case INTEL_FAM6_SKYLAKE_X:
pmem = true;
+ /* fall through */
case INTEL_FAM6_SKYLAKE_MOBILE:
case INTEL_FAM6_SKYLAKE_DESKTOP:
case
[GIT pull] locking/urgent for 5.3-rc2
Linus,
please pull the latest locking-urgent-for-linus git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
locking-urgent-for-linus
up to: 6c11c6e3d5e9: locking/mutex: Test for initialized mutex
A set of locking fixes:
- Address the fallout of the rwsem rework. Missing ACQUIREs and a sanity
check to prevent a use-after-free
- Add missing checks for unitialized mutexes when mutex debugging is enabled.
- Remove the bogus code in the generic SMP variant of
arch_futex_atomic_op_inuser()
- Fixup the #ifdeffery in lockdep to prevent compile warnings
Thanks,
tglx
-->
Arnd Bergmann (2):
locking/lockdep: Hide unused 'class' variable
locking/lockdep: Clean up #ifdef checks
Jan Stancek (1):
locking/rwsem: Add missing ACQUIRE to read_slowpath exit when queue is
empty
Peter Zijlstra (3):
lcoking/rwsem: Add missing ACQUIRE to read_slowpath sleep loop
tty/ldsem, locking/rwsem: Add missing ACQUIRE to read_failed sleep loop
locking/rwsem: Add ACQUIRE comments
Sebastian Andrzej Siewior (1):
locking/mutex: Test for initialized mutex
Vasily Averin (1):
futex: Cleanup generic SMP variant of arch_futex_atomic_op_inuser()
Waiman Long (1):
locking/rwsem: Don't call owner_on_cpu() on read-owner
drivers/tty/tty_ldsem.c | 5 ++---
include/asm-generic/futex.h | 21 +
kernel/locking/lockdep.c | 13 ++---
kernel/locking/lockdep_proc.c | 3 ++-
kernel/locking/mutex.c| 11 ++-
kernel/locking/rwsem.c| 28 ++--
6 files changed, 43 insertions(+), 38 deletions(-)
diff --git a/drivers/tty/tty_ldsem.c b/drivers/tty/tty_ldsem.c
index 717292c1c0df..60ff236a3d63 100644
--- a/drivers/tty/tty_ldsem.c
+++ b/drivers/tty/tty_ldsem.c
@@ -93,8 +93,7 @@ static void __ldsem_wake_readers(struct ld_semaphore *sem)
list_for_each_entry_safe(waiter, next, >read_wait, list) {
tsk = waiter->task;
- smp_mb();
- waiter->task = NULL;
+ smp_store_release(>task, NULL);
wake_up_process(tsk);
put_task_struct(tsk);
}
@@ -194,7 +193,7 @@ down_read_failed(struct ld_semaphore *sem, long count, long
timeout)
for (;;) {
set_current_state(TASK_UNINTERRUPTIBLE);
- if (!waiter.task)
+ if (!smp_load_acquire())
break;
if (!timeout)
break;
diff --git a/include/asm-generic/futex.h b/include/asm-generic/futex.h
index 8666fe7f35d7..02970b11f71f 100644
--- a/include/asm-generic/futex.h
+++ b/include/asm-generic/futex.h
@@ -118,26 +118,7 @@ futex_atomic_cmpxchg_inatomic(u32 *uval, u32 __user *uaddr,
static inline int
arch_futex_atomic_op_inuser(int op, u32 oparg, int *oval, u32 __user *uaddr)
{
- int oldval = 0, ret;
-
- pagefault_disable();
-
- switch (op) {
- case FUTEX_OP_SET:
- case FUTEX_OP_ADD:
- case FUTEX_OP_OR:
- case FUTEX_OP_ANDN:
- case FUTEX_OP_XOR:
- default:
- ret = -ENOSYS;
- }
-
- pagefault_enable();
-
- if (!ret)
- *oval = oldval;
-
- return ret;
+ return -ENOSYS;
}
static inline int
diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c
index 341f52117f88..4861cf8e274b 100644
--- a/kernel/locking/lockdep.c
+++ b/kernel/locking/lockdep.c
@@ -448,7 +448,7 @@ static void print_lockdep_off(const char *bug_msg)
unsigned long nr_stack_trace_entries;
-#if defined(CONFIG_TRACE_IRQFLAGS) && defined(CONFIG_PROVE_LOCKING)
+#ifdef CONFIG_PROVE_LOCKING
/*
* Stack-trace: tightly packed array of stack backtrace
* addresses. Protected by the graph_lock.
@@ -491,7 +491,7 @@ unsigned int max_lockdep_depth;
DEFINE_PER_CPU(struct lockdep_stats, lockdep_stats);
#endif
-#if defined(CONFIG_TRACE_IRQFLAGS) && defined(CONFIG_PROVE_LOCKING)
+#ifdef CONFIG_PROVE_LOCKING
/*
* Locking printouts:
*/
@@ -2969,7 +2969,7 @@ static void check_chain_key(struct task_struct *curr)
#endif
}
-#if defined(CONFIG_TRACE_IRQFLAGS) && defined(CONFIG_PROVE_LOCKING)
+#ifdef CONFIG_PROVE_LOCKING
static int mark_lock(struct task_struct *curr, struct held_lock *this,
enum lock_usage_bit new_bit);
@@ -3608,7 +3608,7 @@ static int mark_lock(struct task_struct *curr, struct
held_lock *this,
return ret;
}
-#else /* defined(CONFIG_TRACE_IRQFLAGS) && defined(CONFIG_PROVE_LOCKING) */
+#else /* CONFIG_PROVE_LOCKING */
static inline int
mark_usage(struct task_struct *curr, struct held_lock *hlock, int check)
@@ -3627,7 +3627,7 @@ static inline int separate_irq_context(struct task_struct
*curr,
return 0;
}
-#endif /* defined(CONFIG_TRACE_IRQFLAGS) && defined(CONFIG_PROVE_LOCKING) */
+#endif /* CONFIG_PROVE_LOCKING */
/*
* Initialize a lock instance's lock-class mapping
[GIT pull] sched/urgent for 5.3-rc2
Linus,
please pull the latest sched-urgent-for-linus git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
sched-urgent-for-linus
up to: cb361d8cdef6: sched/fair: Use RCU accessors consistently for
->numa_group
Two fixes for the fair scheduling class:
- Prevent freeing memory which is accessible by concurrent readers
- Make the RCU annotations for numa groups consistent
Thanks,
tglx
-->
Jann Horn (2):
sched/fair: Don't free p->numa_faults with concurrent readers
sched/fair: Use RCU accessors consistently for ->numa_group
fs/exec.c| 2 +-
include/linux/sched.h| 10 ++-
include/linux/sched/numa_balancing.h | 4 +-
kernel/fork.c| 2 +-
kernel/sched/fair.c | 144 ---
5 files changed, 114 insertions(+), 48 deletions(-)
diff --git a/fs/exec.c b/fs/exec.c
index c71cbfe6826a..f7f6a140856a 100644
--- a/fs/exec.c
+++ b/fs/exec.c
@@ -1828,7 +1828,7 @@ static int __do_execve_file(int fd, struct filename
*filename,
membarrier_execve(current);
rseq_execve(current);
acct_update_integrals(current);
- task_numa_free(current);
+ task_numa_free(current, false);
free_bprm(bprm);
kfree(pathbuf);
if (filename)
diff --git a/include/linux/sched.h b/include/linux/sched.h
index 8dc1811487f5..9f51932bd543 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -1092,7 +1092,15 @@ struct task_struct {
u64 last_sum_exec_runtime;
struct callback_headnuma_work;
- struct numa_group *numa_group;
+ /*
+* This pointer is only modified for current in syscall and
+* pagefault context (and for tasks being destroyed), so it can be read
+* from any of the following contexts:
+* - RCU read-side critical section
+* - current->numa_group from everywhere
+* - task's runqueue locked, task not running
+*/
+ struct numa_group __rcu *numa_group;
/*
* numa_faults is an array split into four regions:
diff --git a/include/linux/sched/numa_balancing.h
b/include/linux/sched/numa_balancing.h
index e7dd04a84ba8..3988762efe15 100644
--- a/include/linux/sched/numa_balancing.h
+++ b/include/linux/sched/numa_balancing.h
@@ -19,7 +19,7 @@
extern void task_numa_fault(int last_node, int node, int pages, int flags);
extern pid_t task_numa_group_id(struct task_struct *p);
extern void set_numabalancing_state(bool enabled);
-extern void task_numa_free(struct task_struct *p);
+extern void task_numa_free(struct task_struct *p, bool final);
extern bool should_numa_migrate_memory(struct task_struct *p, struct page
*page,
int src_nid, int dst_cpu);
#else
@@ -34,7 +34,7 @@ static inline pid_t task_numa_group_id(struct task_struct *p)
static inline void set_numabalancing_state(bool enabled)
{
}
-static inline void task_numa_free(struct task_struct *p)
+static inline void task_numa_free(struct task_struct *p, bool final)
{
}
static inline bool should_numa_migrate_memory(struct task_struct *p,
diff --git a/kernel/fork.c b/kernel/fork.c
index d8ae0f1b4148..2852d0e76ea3 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -726,7 +726,7 @@ void __put_task_struct(struct task_struct *tsk)
WARN_ON(tsk == current);
cgroup_free(tsk);
- task_numa_free(tsk);
+ task_numa_free(tsk, true);
security_task_free(tsk);
exit_creds(tsk);
delayacct_tsk_free(tsk);
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 036be95a87e9..bc9cfeaac8bd 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -1086,6 +1086,21 @@ struct numa_group {
unsigned long faults[0];
};
+/*
+ * For functions that can be called in multiple contexts that permit reading
+ * ->numa_group (see struct task_struct for locking rules).
+ */
+static struct numa_group *deref_task_numa_group(struct task_struct *p)
+{
+ return rcu_dereference_check(p->numa_group, p == current ||
+ (lockdep_is_held(_rq(p)->lock) && !READ_ONCE(p->on_cpu)));
+}
+
+static struct numa_group *deref_curr_numa_group(struct task_struct *p)
+{
+ return rcu_dereference_protected(p->numa_group, p == current);
+}
+
static inline unsigned long group_faults_priv(struct numa_group *ng);
static inline unsigned long group_faults_shared(struct numa_group *ng);
@@ -1129,10 +1144,12 @@ static unsigned int task_scan_start(struct task_struct
*p)
{
unsigned long smin = task_scan_min(p);
unsigned long period = smin;
+ struct numa_group *ng;
/* Scale the maximum scan period with the amount of shared memory. */
- if (p->numa_group) {
- struct numa_group *ng = p->numa_group;
+ rcu_read_lock();
+ ng =
[GIT pull] x86/urgent for 5.3-rc2
Linus,
please pull the latest x86-urgent-for-linus git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
x86-urgent-for-linus
up to: 517c3ba00916: x86/speculation/mds: Apply more accurate check on
hypervisor platform
A set of x86 fixes and functional updates:
- Prevent stale huge I/O TLB mappings on 32bit. A long standing bug which got
exposed by KPTI support for 32bit
- Prevent bogus access_ok() warnings in arch_stack_walk_user()
- Add display quirks for Lenovo devices which have height and width swapped
- Add the missing CR2 fixup for 32 bit async pagefaults. Fallout of the
CR2 bug fix series.
- Unbreak handling of force enabled HPET by moving the 'is HPET counting'
check back to the original place.
- A more accurate check for running on a hypervisor platform in the MDS
mitigation code. Not perfect, but more accurate than the previous one.
- Update a stale and confusing comment vs. IRQ stacks
Thanks,
tglx
-->
Cao jin (1):
x86/irq/64: Update stale comment
Eiichi Tsukata (1):
x86/stacktrace: Prevent access_ok() warnings in arch_stack_walk_user()
Hans de Goede (1):
x86/sysfb_efi: Add quirks for some devices with swapped width and height
Joerg Roedel (3):
x86/mm: Check for pfn instead of page in vmalloc_sync_one()
x86/mm: Sync also unmappings in vmalloc_sync_all()
mm/vmalloc: Sync unmappings in __purge_vmap_area_lazy()
Matt Mullins (1):
x86/entry/32: Pass cr2 to do_async_page_fault()
Thomas Gleixner (1):
x86/hpet: Undo the early counter is counting check
Zhenzhong Duan (1):
x86/speculation/mds: Apply more accurate check on hypervisor platform
arch/x86/entry/entry_32.S| 13 +
arch/x86/kernel/cpu/bugs.c | 2 +-
arch/x86/kernel/head_64.S| 8
arch/x86/kernel/hpet.c | 12
arch/x86/kernel/stacktrace.c | 2 +-
arch/x86/kernel/sysfb_efi.c | 46
arch/x86/mm/fault.c | 15 ++-
mm/vmalloc.c | 9 +
8 files changed, 84 insertions(+), 23 deletions(-)
diff --git a/arch/x86/entry/entry_32.S b/arch/x86/entry/entry_32.S
index 2bb986f305ac..4f86928246e7 100644
--- a/arch/x86/entry/entry_32.S
+++ b/arch/x86/entry/entry_32.S
@@ -1443,8 +1443,12 @@ BUILD_INTERRUPT3(hv_stimer0_callback_vector,
HYPERV_STIMER0_VECTOR,
ENTRY(page_fault)
ASM_CLAC
- pushl $0; /* %gs's slot on the stack */
+ pushl $do_page_fault
+ jmp common_exception_read_cr2
+END(page_fault)
+common_exception_read_cr2:
+ /* the function address is in %gs's slot on the stack */
SAVE_ALL switch_stacks=1 skip_gs=1
ENCODE_FRAME_POINTER
@@ -1452,6 +1456,7 @@ ENTRY(page_fault)
/* fixup %gs */
GS_TO_REG %ecx
+ movlPT_GS(%esp), %edi
REG_TO_PTGS %ecx
SET_KERNEL_GS %ecx
@@ -1463,9 +1468,9 @@ ENTRY(page_fault)
TRACE_IRQS_OFF
movl%esp, %eax # pt_regs pointer
- calldo_page_fault
+ CALL_NOSPEC %edi
jmp ret_from_exception
-END(page_fault)
+END(common_exception_read_cr2)
common_exception:
/* the function address is in %gs's slot on the stack */
@@ -1595,7 +1600,7 @@ END(general_protection)
ENTRY(async_page_fault)
ASM_CLAC
pushl $do_async_page_fault
- jmp common_exception
+ jmp common_exception_read_cr2
END(async_page_fault)
#endif
diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c
index 66ca906aa790..801ecd1c3fd5 100644
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -1226,7 +1226,7 @@ static ssize_t l1tf_show_state(char *buf)
static ssize_t mds_show_state(char *buf)
{
- if (!hypervisor_is_type(X86_HYPER_NATIVE)) {
+ if (boot_cpu_has(X86_FEATURE_HYPERVISOR)) {
return sprintf(buf, "%s; SMT Host state unknown\n",
mds_strings[mds_mitigation]);
}
diff --git a/arch/x86/kernel/head_64.S b/arch/x86/kernel/head_64.S
index a6342c899be5..f3d3e9646a99 100644
--- a/arch/x86/kernel/head_64.S
+++ b/arch/x86/kernel/head_64.S
@@ -193,10 +193,10 @@ ENTRY(secondary_startup_64)
/* Set up %gs.
*
-* The base of %gs always points to the bottom of the irqstack
-* union. If the stack protector canary is enabled, it is
-* located at %gs:40. Note that, on SMP, the boot cpu uses
-* init data section till per cpu areas are set up.
+* The base of %gs always points to fixed_percpu_data. If the
+* stack protector canary is enabled, it is located at %gs:40.
+* Note that, on SMP, the boot cpu uses init data section until
+* the per cpu areas are set up.
*/
movl$MSR_GS_BASE,%ecx
movlinitial_gs(%rip),%eax
diff --git a/arch/x86/kernel/hpet.c b/arch/x86/kernel/hpet.c
index
[GIT pull] core/urgent for 5.3-rc2
Linus,
please pull the latest core-urgent-for-linus git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
core-urgent-for-linus
up to: 882a0db9d143: objtool: Improve UACCESS coverage
A single robustness fix for objtool to handle unbalanced CLAC invocations
under all circumstances.
Thanks,
tglx
-->
Peter Zijlstra (1):
objtool: Improve UACCESS coverage
tools/objtool/check.c | 7 ---
tools/objtool/check.h | 3 ++-
2 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/tools/objtool/check.c b/tools/objtool/check.c
index 5f26620f13f5..176f2f084060 100644
--- a/tools/objtool/check.c
+++ b/tools/objtool/check.c
@@ -1946,6 +1946,7 @@ static int validate_branch(struct objtool_file *file,
struct symbol *func,
struct alternative *alt;
struct instruction *insn, *next_insn;
struct section *sec;
+ u8 visited;
int ret;
insn = first;
@@ -1972,12 +1973,12 @@ static int validate_branch(struct objtool_file *file,
struct symbol *func,
return 1;
}
+ visited = 1 << state.uaccess;
if (insn->visited) {
if (!insn->hint && !insn_state_match(insn, ))
return 1;
- /* If we were here with AC=0, but now have AC=1, go
again */
- if (insn->state.uaccess || !state.uaccess)
+ if (insn->visited & visited)
return 0;
}
@@ -2024,7 +2025,7 @@ static int validate_branch(struct objtool_file *file,
struct symbol *func,
} else
insn->state = state;
- insn->visited = true;
+ insn->visited |= visited;
if (!insn->ignore_alts) {
bool skip_orig = false;
diff --git a/tools/objtool/check.h b/tools/objtool/check.h
index b881fafcf55d..6d875ca6fce0 100644
--- a/tools/objtool/check.h
+++ b/tools/objtool/check.h
@@ -33,8 +33,9 @@ struct instruction {
unsigned int len;
enum insn_type type;
unsigned long immediate;
- bool alt_group, visited, dead_end, ignore, hint, save, restore,
ignore_alts;
+ bool alt_group, dead_end, ignore, hint, save, restore, ignore_alts;
bool retpoline_safe;
+ u8 visited;
struct symbol *call_dest;
struct instruction *jump_dest;
struct instruction *first_jump_src;
[PATCH v3 1/2] pidfd: add P_PIDFD to waitid()
This adds the P_PIDFD type to waitid().
One of the last remaining bits for the pidfd api is to make it possible
to wait on pidfds. With P_PIDFD added to waitid() the parts of userspace
that want to use the pidfd api to exclusively manage processes can do so
now.
One of the things this will unblock in the future is the ability to make
it possible to retrieve the exit status via waitid(P_PIDFD) for
non-parent processes if handed a _suitable_ pidfd that has this feature
set. This is similar to what you can do on FreeBSD with kqueue(). It
might even end up being possible to wait on a process as a non-parent if
an appropriate property is enabled on the pidfd.
With P_PIDFD no scoping of the process identified by the pidfd is
possible, i.e. it explicitly blocks things such as wait4(-1), wait4(0),
waitid(P_ALL), waitid(P_PGID) etc. It only allows for semantics
equivalent to wait4(pid), waitid(P_PID). Users that need scoping should
rely on pid-based wait*() syscalls for now.
Signed-off-by: Christian Brauner
Cc: Arnd Bergmann
Cc: "Eric W. Biederman"
Cc: Kees Cook
Cc: Joel Fernandes (Google)
Cc: Thomas Gleixner
Cc: David Howells
Cc: Jann Horn
Cc: Andy Lutomirsky
Cc: Andrew Morton
Cc: Oleg Nesterov
Cc: Aleksa Sarai
Cc: Linus Torvalds
Cc: Al Viro
---
v1:
- Linus Torvalds :
- use flag as discussed before, not a dedicated pidfd_wait() syscall
- Oleg Nesterov :
- use flag as discussed before, not a dedicated pidfd_wait() syscall
v2:
- Linus Torvalds :
- move find_get_pid() calls into switch statements to avoid checking
the type argument twice
v3:
- Linus Torvalds :
- add a dedicated helper which does the transformation from pidfd to
struct pid to avoid open coding this
- take an additional reference to struct pid to keep the exit code
unified
---
include/linux/pid.h | 4
include/uapi/linux/wait.h | 1 +
kernel/exit.c | 33 ++---
kernel/fork.c | 8
kernel/signal.c | 7 +--
5 files changed, 48 insertions(+), 5 deletions(-)
diff --git a/include/linux/pid.h b/include/linux/pid.h
index 2a83e434db9d..9645b1194c98 100644
--- a/include/linux/pid.h
+++ b/include/linux/pid.h
@@ -72,6 +72,10 @@ extern struct pid init_struct_pid;
extern const struct file_operations pidfd_fops;
+struct file;
+
+extern struct pid *pidfd_pid(const struct file *file);
+
static inline struct pid *get_pid(struct pid *pid)
{
if (pid)
diff --git a/include/uapi/linux/wait.h b/include/uapi/linux/wait.h
index ac49a220cf2a..85b809fc9f11 100644
--- a/include/uapi/linux/wait.h
+++ b/include/uapi/linux/wait.h
@@ -17,6 +17,7 @@
#define P_ALL 0
#define P_PID 1
#define P_PGID 2
+#define P_PIDFD3
#endif /* _UAPI_LINUX_WAIT_H */
diff --git a/kernel/exit.c b/kernel/exit.c
index a75b6a7f458a..64bb6893a37d 100644
--- a/kernel/exit.c
+++ b/kernel/exit.c
@@ -1552,6 +1552,23 @@ static long do_wait(struct wait_opts *wo)
return retval;
}
+static struct pid *pidfd_get_pid(unsigned int fd)
+{
+ struct fd f;
+ struct pid *pid;
+
+ f = fdget(fd);
+ if (!f.file)
+ return ERR_PTR(-EBADF);
+
+ pid = pidfd_pid(f.file);
+ if (!IS_ERR(pid))
+ get_pid(pid);
+
+ fdput(f);
+ return pid;
+}
+
static long kernel_waitid(int which, pid_t upid, struct waitid_info *infop,
int options, struct rusage *ru)
{
@@ -1574,19 +1591,29 @@ static long kernel_waitid(int which, pid_t upid, struct
waitid_info *infop,
type = PIDTYPE_PID;
if (upid <= 0)
return -EINVAL;
+
+ pid = find_get_pid(upid);
break;
case P_PGID:
type = PIDTYPE_PGID;
if (upid <= 0)
return -EINVAL;
+
+ pid = find_get_pid(upid);
+ break;
+ case P_PIDFD:
+ type = PIDTYPE_PID;
+ if (upid < 0)
+ return -EINVAL;
+
+ pid = pidfd_get_pid(upid);
+ if (IS_ERR(pid))
+ return PTR_ERR(pid);
break;
default:
return -EINVAL;
}
- if (type < PIDTYPE_MAX)
- pid = find_get_pid(upid);
-
wo.wo_type = type;
wo.wo_pid = pid;
wo.wo_flags = options;
diff --git a/kernel/fork.c b/kernel/fork.c
index d8ae0f1b4148..b169e2ca2d84 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -1690,6 +1690,14 @@ static inline void rcu_copy_process(struct task_struct
*p)
#endif /* #ifdef CONFIG_TASKS_RCU */
}
+struct pid *pidfd_pid(const struct file *file)
+{
+ if (file->f_op == _fops)
+ return file->private_data;
+
+ return ERR_PTR(-EBADF);
+}
+
static int pidfd_release(struct inode *inode, struct file *file)
{
struct pid *pid = file->private_data;
[PATCH v3 2/2] pidfd: add pidfd_wait tests
Add tests for pidfd_wait() and CLONE_WAIT_PID:
- test that waitid(P_PIDFD) can wait on a pidfd
- test that waitid(P_PIDFD) can wait on a pidfd and return siginfo_t
- test that waitid(P_PIDFD) works with WEXITED
- test that waitid(P_PIDFD) works with WSTOPPED
- test that waitid(P_PIDFD) works with WUNTRACED
- test that waitid(P_PIDFD) works with WCONTINUED
- test that waitid(P_PIDFD) works with WNOWAIT
- test that waitid(P_PIDFD)works with WNOHANG
Signed-off-by: Christian Brauner
Cc: Arnd Bergmann
Cc: "Eric W. Biederman"
Cc: Kees Cook
Cc: Joel Fernandes (Google)
Cc: Thomas Gleixner
Cc: David Howells
Cc: Jann Horn
Cc: Andy Lutomirsky
Cc: Andrew Morton
Cc: Oleg Nesterov
Cc: Aleksa Sarai
Cc: Linus Torvalds
Cc: Al Viro
---
v1:
- Christian Brauner :
- adapt tests to new P_PIDFD concept
v2: unchanged
v3:
- Christian Brauner :
- add a test for passing an invalid pidfd
---
tools/testing/selftests/pidfd/pidfd.h | 25 ++
tools/testing/selftests/pidfd/pidfd_test.c | 14 --
tools/testing/selftests/pidfd/pidfd_wait.c | 258 +
3 files changed, 283 insertions(+), 14 deletions(-)
create mode 100644 tools/testing/selftests/pidfd/pidfd_wait.c
diff --git a/tools/testing/selftests/pidfd/pidfd.h
b/tools/testing/selftests/pidfd/pidfd.h
index 8452e910463f..7d7d0ca05e0b 100644
--- a/tools/testing/selftests/pidfd/pidfd.h
+++ b/tools/testing/selftests/pidfd/pidfd.h
@@ -16,6 +16,26 @@
#include "../kselftest.h"
+#ifndef P_PIDFD
+#define P_PIDFD 3
+#endif
+
+#ifndef CLONE_PIDFD
+#define CLONE_PIDFD 0x1000
+#endif
+
+#ifndef __NR_pidfd_open
+#define __NR_pidfd_open -1
+#endif
+
+#ifndef __NR_pidfd_send_signal
+#define __NR_pidfd_send_signal -1
+#endif
+
+#ifndef __NR_clone3
+#define __NR_clone3 -1
+#endif
+
/*
* The kernel reserves 300 pids via RESERVED_PIDS in kernel/pid.c
* That means, when it wraps around any pid < 300 will be skipped.
@@ -53,5 +73,10 @@ int wait_for_pid(pid_t pid)
return WEXITSTATUS(status);
}
+static inline int sys_pidfd_send_signal(int pidfd, int sig, siginfo_t *info,
+ unsigned int flags)
+{
+ return syscall(__NR_pidfd_send_signal, pidfd, sig, info, flags);
+}
#endif /* __PIDFD_H */
diff --git a/tools/testing/selftests/pidfd/pidfd_test.c
b/tools/testing/selftests/pidfd/pidfd_test.c
index 7eaa8a3de262..42e3eb494d72 100644
--- a/tools/testing/selftests/pidfd/pidfd_test.c
+++ b/tools/testing/selftests/pidfd/pidfd_test.c
@@ -21,20 +21,12 @@
#include "pidfd.h"
#include "../kselftest.h"
-#ifndef __NR_pidfd_send_signal
-#define __NR_pidfd_send_signal -1
-#endif
-
#define str(s) _str(s)
#define _str(s) #s
#define CHILD_THREAD_MIN_WAIT 3 /* seconds */
#define MAX_EVENTS 5
-#ifndef CLONE_PIDFD
-#define CLONE_PIDFD 0x1000
-#endif
-
static pid_t pidfd_clone(int flags, int *pidfd, int (*fn)(void *))
{
size_t stack_size = 1024;
@@ -47,12 +39,6 @@ static pid_t pidfd_clone(int flags, int *pidfd, int
(*fn)(void *))
#endif
}
-static inline int sys_pidfd_send_signal(int pidfd, int sig, siginfo_t *info,
- unsigned int flags)
-{
- return syscall(__NR_pidfd_send_signal, pidfd, sig, info, flags);
-}
-
static int signal_received;
static void set_signal_received_on_sigusr1(int sig)
diff --git a/tools/testing/selftests/pidfd/pidfd_wait.c
b/tools/testing/selftests/pidfd/pidfd_wait.c
new file mode 100644
index ..887c086d98ab
--- /dev/null
+++ b/tools/testing/selftests/pidfd/pidfd_wait.c
@@ -0,0 +1,258 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+
+#define _GNU_SOURCE
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "pidfd.h"
+#include "../kselftest.h"
+
+#define ptr_to_u64(ptr) ((__u64)((uintptr_t)(ptr)))
+
+static pid_t sys_clone3(struct clone_args *args)
+{
+ return syscall(__NR_clone3, args, sizeof(struct clone_args));
+}
+
+static int sys_waitid(int which, pid_t pid, siginfo_t *info, int options,
+ struct rusage *ru)
+{
+ return syscall(__NR_waitid, which, pid, info, options, ru);
+}
+
+static int test_pidfd_wait_simple(void)
+{
+ const char *test_name = "pidfd wait simple";
+ int pidfd = -1, status = 0;
+ pid_t parent_tid = -1;
+ struct clone_args args = {
+ .parent_tid = ptr_to_u64(_tid),
+ .pidfd = ptr_to_u64(),
+ .flags = CLONE_PIDFD | CLONE_PARENT_SETTID,
+ .exit_signal = SIGCHLD,
+ };
+ int ret;
+ pid_t pid;
+ siginfo_t info = {
+ .si_signo = 0,
+ };
+
+ pidfd = open("/proc/self", O_DIRECTORY | O_RDONLY | O_CLOEXEC);
+ if (pidfd < 0)
+ ksft_exit_fail_msg("%s test: failed to open /proc/self %s\n",
+ test_name, strerror(errno));
+
+ pid = sys_waitid(P_PIDFD, pidfd, , WEXITED, NULL);
+
[PATCH v3 0/2] pidfd: waiting on processes through pidfds
Hey everyone, /* v3 */ This adds the ability to wait on processes using pidfds. This is one of the few missing pieces to make it possible to manage processes using only pidfds. Now major changes have occured since v2. The only thing that was changed has been to move the translation of a pidfd into a struct pid to a dedicated helper that also does a get_pid() on it to keep the exit code identical for all switch cases. I've also added a test to verify that we correctly fail when an invalid file descriptor is passed. The core patch for waitid is pleasantly small. The largest change is caused by adding proper tests for waitid(P_PIDFD). /* v2 */ Link: https://lore.kernel.org/lkml/20190727085201.11743-1-christ...@brauner.io /* v1 */ Link: https://lore.kernel.org/lkml/20190726093934.13557-1-christ...@brauner.io /* v0 */ Link: https://lore.kernel.org/lkml/20190724144651.28272-1-christ...@brauner.io Christian Christian Brauner (2): pidfd: add P_PIDFD to waitid() pidfd: add pidfd_wait tests include/linux/pid.h| 4 + include/uapi/linux/wait.h | 1 + kernel/exit.c | 33 ++- kernel/fork.c | 8 + kernel/signal.c| 7 +- tools/testing/selftests/pidfd/pidfd.h | 25 ++ tools/testing/selftests/pidfd/pidfd_test.c | 14 -- tools/testing/selftests/pidfd/pidfd_wait.c | 258 + 8 files changed, 331 insertions(+), 19 deletions(-) create mode 100644 tools/testing/selftests/pidfd/pidfd_wait.c -- 2.22.0
Re: [PATCH v5 1/1] iio: common: cros_ec_sensors: Expose cros_ec_sensors frequency range via iio sysfs
On Tue, 16 Jul 2019 11:11:06 +0200
Fabien Lahoudere wrote:
> Embedded controller return minimum and maximum frequencies, unfortunately
> we have no way to know the step for all available frequencies.
> Even if not complete, we can return a list of known values using the
> standard read_avail callback (IIO_CHAN_INFO_SAMP_FREQ) to provide them to
> userland.
>
> Now cros_ec_* sensors provides frequencies values in sysfs like this:
> "0 min max". 0 is always true to disable the sensor.
>
> Default frequencies are provided for earlier protocol.
>
> Signed-off-by: Nick Vaccaro
> Signed-off-by: Fabien Lahoudere
> Acked-by: Jonathan Cameron
I applied a version Enric had rebased. Hopefully it matches this!
Was easier than repeating his conflict resolution.
thanks,
Jonathan
> ---
> .../common/cros_ec_sensors/cros_ec_sensors.c | 3 +
> .../cros_ec_sensors/cros_ec_sensors_core.c| 65 +++
> drivers/iio/light/cros_ec_light_prox.c| 3 +
> .../linux/iio/common/cros_ec_sensors_core.h | 21 ++
> 4 files changed, 92 insertions(+)
>
> diff --git a/drivers/iio/common/cros_ec_sensors/cros_ec_sensors.c
> b/drivers/iio/common/cros_ec_sensors/cros_ec_sensors.c
> index 17af4e0fd5f8..dbca02688c4f 100644
> --- a/drivers/iio/common/cros_ec_sensors/cros_ec_sensors.c
> +++ b/drivers/iio/common/cros_ec_sensors/cros_ec_sensors.c
> @@ -175,6 +175,7 @@ static int cros_ec_sensors_write(struct iio_dev
> *indio_dev,
> static const struct iio_info ec_sensors_info = {
> .read_raw = _ec_sensors_read,
> .write_raw = _ec_sensors_write,
> + .read_avail = _ec_sensors_core_read_avail,
> };
>
> static int cros_ec_sensors_probe(struct platform_device *pdev)
> @@ -211,6 +212,8 @@ static int cros_ec_sensors_probe(struct platform_device
> *pdev)
> BIT(IIO_CHAN_INFO_SCALE) |
> BIT(IIO_CHAN_INFO_FREQUENCY) |
> BIT(IIO_CHAN_INFO_SAMP_FREQ);
> + channel->info_mask_shared_by_all_available =
> + BIT(IIO_CHAN_INFO_SAMP_FREQ);
> channel->scan_type.realbits = CROS_EC_SENSOR_BITS;
> channel->scan_type.storagebits = CROS_EC_SENSOR_BITS;
> channel->scan_index = i;
> diff --git a/drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c
> b/drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c
> index 8af8a167..805652250960 100644
> --- a/drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c
> +++ b/drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c
> @@ -50,6 +50,37 @@ static int cros_ec_get_host_cmd_version_mask(struct
> cros_ec_device *ec_dev,
> return ret;
> }
>
> +static void get_default_min_max_freq(enum motionsensor_type type,
> + u32 *min_freq,
> + u32 *max_freq)
> +{
> + switch (type) {
> + case MOTIONSENSE_TYPE_ACCEL:
> + case MOTIONSENSE_TYPE_GYRO:
> + *min_freq = 12500;
> + *max_freq = 10;
> + break;
> + case MOTIONSENSE_TYPE_MAG:
> + *min_freq = 5000;
> + *max_freq = 25000;
> + break;
> + case MOTIONSENSE_TYPE_PROX:
> + case MOTIONSENSE_TYPE_LIGHT:
> + *min_freq = 100;
> + *max_freq = 5;
> + break;
> + case MOTIONSENSE_TYPE_BARO:
> + *min_freq = 250;
> + *max_freq = 2;
> + break;
> + case MOTIONSENSE_TYPE_ACTIVITY:
> + default:
> + *min_freq = 0;
> + *max_freq = 0;
> + break;
> + }
> +}
> +
> int cros_ec_sensors_core_init(struct platform_device *pdev,
> struct iio_dev *indio_dev,
> bool physical_device)
> @@ -100,6 +131,19 @@ int cros_ec_sensors_core_init(struct platform_device
> *pdev,
> }
> state->type = state->resp->info.type;
> state->loc = state->resp->info.location;
> +
> + /* 0 is a correct value used to stop the device */
> + state->frequencies[0] = 0;
> + if (state->msg->version < 3) {
> + get_default_min_max_freq(state->resp->info.type,
> + >frequencies[1],
> + >frequencies[2]);
> + } else {
> + state->frequencies[1] =
> + state->resp->info_3.min_frequency;
> + state->frequencies[2] =
> + state->resp->info_3.max_frequency;
> + }
> }
>
> return 0;
> @@ -461,6 +505,27 @@ int cros_ec_sensors_core_read(struct
> cros_ec_sensors_core_state *st,
> }
> EXPORT_SYMBOL_GPL(cros_ec_sensors_core_read);
>
> +int cros_ec_sensors_core_read_avail(struct iio_dev *indio_dev,
> + struct iio_chan_spec const *chan,
> +
Re: [PATCH v4 1/4] iio: cros_ec: Add sign vector in core for backward compatibility
On Mon, 22 Jul 2019 16:53:41 +0200
Enric Balletbo i Serra wrote:
> Hi Jonathan,
>
> On 14/7/19 18:32, Jonathan Cameron wrote:
> > On Fri, 28 Jun 2019 12:17:08 -0700
> > Gwendal Grignou wrote:
> >
> >> To allow cros_ec iio core library to be used with legacy device, add a
> >> vector to rotate sensor data if necessary: legacy devices are not
> >> reporting data in HTML5/Android sensor referential.
> >>
> >> Check the data is not rotated on recent chromebooks that use the HTML5
> >> standard to present sensor data.
> >>
> >> Signed-off-by: Gwendal Grignou
> >> Reviewed-by: Douglas Anderson
> > Acked-by: Jonathan Cameron
> >
> > As I mentioned in one of the other series. I've lost track of whether
> > anyone wants me to apply any of these through IIO, so will just ack
> > them as appropriate and assume someone will shout if they do want
> > me to pick them up ;)
> >
>
> To try to give you a bit of light on this, all the required changes in
> chrome-platform are now in upstream so all the patches can go safely through
> your tree. The order to pick the patches is as follow:
>
>
> 1096491 [v4,1/1] iio: common: cros_ec_sensors: determine protocol version
>
> 1100922 [v6,1/4] iio: cros_ec: Add sign vector in core for backward
> compatibility
> 1100924 [v6,3/4] iio: cros_ec_accel_legacy: Use cros_ec_sensors_core
> 1100923 [v6,4/4] iio: cros_ec_accel_legacy: Add support for veyron-minnie
>
> 1100982 [v5,1/1] iio: common: cros_ec_sensors: Expose cros_ec_sensors
> frequency
> range via iio sysfs
>
> But if you try to apply latest versions from patchwork you'll get some trivial
> conflicts. So, I fixed the problems, rebased on top of your testing branch,
> added my Rb tag to all the patches and put together in this branch [1]
>
> All the patches have your Ack, so should be fine if you apply all of them just
> replacing your Ack for your Signed-off
Thanks! This is very helpful indeed.
I've done exactly - well sort of :)
Note I did get:
drivers/iio/light/cros_ec_light_prox.c:120:9: warning: ‘ret’ may be used
uninitialized in this function [-Wmaybe-uninitialized]
120 | return ret;
| ^~~
Which looks like a bug, as there is one path under
case IIO_CHAN_INFO_CALIBBIAS:
that got caught by gcc.
Ah, it's my merge mess up on an earlier patch. I'll fix it and post
in reply to that patch.
Also I swapped in the v6 of the veyron_minnie patches and v5 of the sysfs one
as your branch predates those I think.
Thanks,
Jonathan
>
> I can also send a new patch series with those if you prefer this option.
>
> Hopefully is more clear now and sorry for that mess.
> ~ Enric
>
> [1]
> https://git.kernel.org/pub/scm/linux/kernel/git/chrome-platform/linux.git/log/?h=for-iio-next
>
>
> > Thanks,
> >
> > Jonathan
> >
> >> ---
> >> drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c | 4
> >> include/linux/iio/common/cros_ec_sensors_core.h | 1 +
> >> 2 files changed, 5 insertions(+)
> >>
> >> diff --git a/drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c
> >> b/drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c
> >> index 719a0df5aeeb..e8a4d78659c8 100644
> >> --- a/drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c
> >> +++ b/drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c
> >> @@ -66,6 +66,9 @@ int cros_ec_sensors_core_init(struct platform_device
> >> *pdev,
> >>}
> >>state->type = state->resp->info.type;
> >>state->loc = state->resp->info.location;
> >> +
> >> + /* Set sign vector, only used for backward compatibility. */
> >> + memset(state->sign, 1, CROS_EC_SENSOR_MAX_AXIS);
> >>}
> >>
> >>return 0;
> >> @@ -254,6 +257,7 @@ static int cros_ec_sensors_read_data_unsafe(struct
> >> iio_dev *indio_dev,
> >>if (ret < 0)
> >>return ret;
> >>
> >> + *data *= st->sign[i];
> >>data++;
> >>}
> >>
> >> diff --git a/include/linux/iio/common/cros_ec_sensors_core.h
> >> b/include/linux/iio/common/cros_ec_sensors_core.h
> >> index ce16445411ac..a1c85ad4df91 100644
> >> --- a/include/linux/iio/common/cros_ec_sensors_core.h
> >> +++ b/include/linux/iio/common/cros_ec_sensors_core.h
> >> @@ -71,6 +71,7 @@ struct cros_ec_sensors_core_state {
> >>enum motionsensor_location loc;
> >>
> >>s16 calib[CROS_EC_SENSOR_MAX_AXIS];
> >> + s8 sign[CROS_EC_SENSOR_MAX_AXIS];
> >>
> >>u8 samples[CROS_EC_SAMPLE_SIZE];
> >>
> >
Re: [PATCH v6 3/4] iio: cros_ec_accel_legacy: Use cros_ec_sensors_core
On Tue, 16 Jul 2019 10:46:44 +0200
Enric Balletbo i Serra wrote:
> On 16/7/19 1:14, Gwendal Grignou wrote:
> > Remove duplicate code in cros-ec-accel-legacy,
> > use cros-ec-sensors-core functions and structures when possible.
> >
> > On glimmer, check the 2 accelerometers are presented and working.
> >
> > Signed-off-by: Gwendal Grignou
> > Acked-by: Jonathan Cameron
>
> As the mutex problem is fixed:
>
> Reviewed-by: Enric Balletbo i Serra
>
Applied,
Thanks,
Jonathan
> > ---
> > drivers/iio/accel/Kconfig| 4 +-
> > drivers/iio/accel/cros_ec_accel_legacy.c | 336 ---
> > 2 files changed, 55 insertions(+), 285 deletions(-)
> >
> > diff --git a/drivers/iio/accel/Kconfig b/drivers/iio/accel/Kconfig
> > index 62a970a20219..7d0848f9ea45 100644
> > --- a/drivers/iio/accel/Kconfig
> > +++ b/drivers/iio/accel/Kconfig
> > @@ -201,9 +201,7 @@ config HID_SENSOR_ACCEL_3D
> >
> > config IIO_CROS_EC_ACCEL_LEGACY
> > tristate "ChromeOS EC Legacy Accelerometer Sensor"
> > - select IIO_BUFFER
> > - select IIO_TRIGGERED_BUFFER
> > - select CROS_EC_LPC_REGISTER_DEVICE
> > + depends on IIO_CROS_EC_SENSORS_CORE
> > help
> > Say yes here to get support for accelerometers on Chromebook using
> > legacy EC firmware.
> > diff --git a/drivers/iio/accel/cros_ec_accel_legacy.c
> > b/drivers/iio/accel/cros_ec_accel_legacy.c
> > index ad19d9c716f4..f65578c65a1c 100644
> > --- a/drivers/iio/accel/cros_ec_accel_legacy.c
> > +++ b/drivers/iio/accel/cros_ec_accel_legacy.c
> > @@ -12,6 +12,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -25,191 +26,51 @@
> >
> > #define DRV_NAME "cros-ec-accel-legacy"
> >
> > +#define CROS_EC_SENSOR_LEGACY_NUM 2
> > /*
> > * Sensor scale hard coded at 10 bits per g, computed as:
> > * g / (2^10 - 1) = 0.009586168; with g = 9.80665 m.s^-2
> > */
> > #define ACCEL_LEGACY_NSCALE 9586168
> >
> > -/* Indices for EC sensor values. */
> > -enum {
> > - X,
> > - Y,
> > - Z,
> > - MAX_AXIS,
> > -};
> > -
> > -/* State data for cros_ec_accel_legacy iio driver. */
> > -struct cros_ec_accel_legacy_state {
> > - struct cros_ec_device *ec;
> > -
> > - /*
> > -* Array holding data from a single capture. 2 bytes per channel
> > -* for the 3 channels plus the timestamp which is always last and
> > -* 8-bytes aligned.
> > -*/
> > - s16 capture_data[8];
> > - s8 sign[MAX_AXIS];
> > - u8 sensor_num;
> > -};
> > -
> > -static int ec_cmd_read_u8(struct cros_ec_device *ec, unsigned int offset,
> > - u8 *dest)
> > -{
> > - return ec->cmd_readmem(ec, offset, 1, dest);
> > -}
> > -
> > -static int ec_cmd_read_u16(struct cros_ec_device *ec, unsigned int offset,
> > - u16 *dest)
> > -{
> > - __le16 tmp;
> > - int ret = ec->cmd_readmem(ec, offset, 2, );
> > -
> > - *dest = le16_to_cpu(tmp);
> > -
> > - return ret;
> > -}
> > -
> > -/**
> > - * read_ec_until_not_busy() - Read from EC status byte until it reads not
> > busy.
> > - * @st: Pointer to state information for device.
> > - *
> > - * This function reads EC status until its busy bit gets cleared. It does
> > not
> > - * wait indefinitely and returns -EIO if the EC status is still busy after
> > a
> > - * few hundreds milliseconds.
> > - *
> > - * Return: 8-bit status if ok, -EIO on error
> > - */
> > -static int read_ec_until_not_busy(struct cros_ec_accel_legacy_state *st)
> > -{
> > - struct cros_ec_device *ec = st->ec;
> > - u8 status;
> > - int attempts = 0;
> > -
> > - ec_cmd_read_u8(ec, EC_MEMMAP_ACC_STATUS, );
> > - while (status & EC_MEMMAP_ACC_STATUS_BUSY_BIT) {
> > - /* Give up after enough attempts, return error. */
> > - if (attempts++ >= 50)
> > - return -EIO;
> > -
> > - /* Small delay every so often. */
> > - if (attempts % 5 == 0)
> > - msleep(25);
> > -
> > - ec_cmd_read_u8(ec, EC_MEMMAP_ACC_STATUS, );
> > - }
> > -
> > - return status;
> > -}
> > -
> > -/**
> > - * read_ec_accel_data_unsafe() - Read acceleration data from EC shared
> > memory.
> > - * @st:Pointer to state information for device.
> > - * @scan_mask: Bitmap of the sensor indices to scan.
> > - * @data: Location to store data.
> > - *
> > - * This is the unsafe function for reading the EC data. It does not
> > guarantee
> > - * that the EC will not modify the data as it is being read in.
> > - */
> > -static void read_ec_accel_data_unsafe(struct cros_ec_accel_legacy_state
> > *st,
> > - unsigned long scan_mask, s16 *data)
> > -{
> > - int i = 0;
> > - int num_enabled = bitmap_weight(_mask, MAX_AXIS);
> > -
> > - /* Read all sensors enabled in scan_mask. Each value is 2 bytes. */
> > - while (num_enabled--) {
> > - i = find_next_bit(_mask, MAX_AXIS, i);
> > -
Re: [PATCH v6 2/4] iio: cros_ec_accel_legacy: Fix incorrect channel setting
On Mon, 15 Jul 2019 16:14:52 -0700
Gwendal Grignou wrote:
> INFO_SCALE is set both for each channel and all channels.
> iio is using all channel setting, so the error was not user visible.
>
> Signed-off-by: Gwendal Grignou
Applied to the togreg branch of iio.git and pushed out as testing
for the autobuilders to play with it.
Thanks,
Jonathan
> ---
> drivers/iio/accel/cros_ec_accel_legacy.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/iio/accel/cros_ec_accel_legacy.c
> b/drivers/iio/accel/cros_ec_accel_legacy.c
> index 46bb2e421bb9..ad19d9c716f4 100644
> --- a/drivers/iio/accel/cros_ec_accel_legacy.c
> +++ b/drivers/iio/accel/cros_ec_accel_legacy.c
> @@ -319,7 +319,6 @@ static const struct iio_chan_spec_ext_info
> cros_ec_accel_legacy_ext_info[] = {
> .modified = 1, \
> .info_mask_separate = \
> BIT(IIO_CHAN_INFO_RAW) |\
> - BIT(IIO_CHAN_INFO_SCALE) | \
> BIT(IIO_CHAN_INFO_CALIBBIAS), \
> .info_mask_shared_by_all = BIT(IIO_CHAN_INFO_SCALE),\
> .ext_info = cros_ec_accel_legacy_ext_info, \
Re: [PATCH v6 1/4] iio: cros_ec: Add sign vector in core for backward compatibility
On Mon, 15 Jul 2019 16:14:51 -0700
Gwendal Grignou wrote:
> To allow cros_ec iio core library to be used with legacy device, add a
> vector to rotate sensor data if necessary: legacy devices are not
> reporting data in HTML5/Android sensor referential.
>
> Check the data is not rotated on recent chromebooks that use the HTML5
> standard to present sensor data.
>
> Signed-off-by: Gwendal Grignou
> Reviewed-by: Douglas Anderson
Applied to the togreg branch of iio.git and pushed out as testing for the
autobuilders to play with it.
Thanks,
Jonathan
> ---
> drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c | 4
> include/linux/iio/common/cros_ec_sensors_core.h | 1 +
> 2 files changed, 5 insertions(+)
>
> diff --git a/drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c
> b/drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c
> index 719a0df5aeeb..e8a4d78659c8 100644
> --- a/drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c
> +++ b/drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c
> @@ -66,6 +66,9 @@ int cros_ec_sensors_core_init(struct platform_device *pdev,
> }
> state->type = state->resp->info.type;
> state->loc = state->resp->info.location;
> +
> + /* Set sign vector, only used for backward compatibility. */
> + memset(state->sign, 1, CROS_EC_SENSOR_MAX_AXIS);
> }
>
> return 0;
> @@ -254,6 +257,7 @@ static int cros_ec_sensors_read_data_unsafe(struct
> iio_dev *indio_dev,
> if (ret < 0)
> return ret;
>
> + *data *= st->sign[i];
> data++;
> }
>
> diff --git a/include/linux/iio/common/cros_ec_sensors_core.h
> b/include/linux/iio/common/cros_ec_sensors_core.h
> index ce16445411ac..a1c85ad4df91 100644
> --- a/include/linux/iio/common/cros_ec_sensors_core.h
> +++ b/include/linux/iio/common/cros_ec_sensors_core.h
> @@ -71,6 +71,7 @@ struct cros_ec_sensors_core_state {
> enum motionsensor_location loc;
>
> s16 calib[CROS_EC_SENSOR_MAX_AXIS];
> + s8 sign[CROS_EC_SENSOR_MAX_AXIS];
>
> u8 samples[CROS_EC_SAMPLE_SIZE];
>
Re: [PATCH v4 1/1] iio: common: cros_ec_sensors: determine protocol version
On Tue, 16 Jul 2019 10:56:38 +0200
Fabien Lahoudere wrote:
> Le dimanche 14 juillet 2019 à 17:19 +0100, Jonathan Cameron a écrit :
> > On Tue, 2 Jul 2019 10:49:38 +0200
> > Fabien Lahoudere wrote:
> >
> > > This patch adds a function to determine which version of the
> > > protocol is used to communicate with EC.
> > >
> > > Signed-off-by: Fabien Lahoudere
> > > Signed-off-by: Nick Vaccaro
> > > Reviewed-by: Gwendal Grignou
> > > Tested-by: Gwendal Grignou
> > > Acked-by: Enric Balletbo i Serra
> > There are so many different series flying around for this driver that
> > I have given up trying to figure out if I should be picking some of
> > them up. I'll ack them on the assumption they'll all go together,
> > but feel free to ping me if you want me to pick some of them up
> > through IIO.
> >
>
> Yes sorry for all that confusing series.
> Enric wanted this patch first and it is independant of others, so feel
> free to pick it. Others patcheshave been sent separately.
Applied.
Thanks,
Jonathan
>
> Thanks
>
> > Acked-by: Jonathan Cameron
> >
> > Thanks,
> >
> > Jonathan
> >
> > > ---
> > > .../cros_ec_sensors/cros_ec_sensors_core.c| 36
> > > ++-
> > > 1 file changed, 35 insertions(+), 1 deletion(-)
> > >
> > > diff --git
> > > a/drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c
> > > b/drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c
> > > index 130362ca421b..8af8a167 100644
> > > --- a/drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c
> > > +++ b/drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c
> > > @@ -25,6 +25,31 @@ static char *cros_ec_loc[] = {
> > > [MOTIONSENSE_LOC_MAX] = "unknown",
> > > };
> > >
> > > +static int cros_ec_get_host_cmd_version_mask(struct cros_ec_device
> > > *ec_dev,
> > > + u16 cmd_offset, u16 cmd,
> > > u32 *mask)
> > > +{
> > > + int ret;
> > > + struct {
> > > + struct cros_ec_command msg;
> > > + union {
> > > + struct ec_params_get_cmd_versions params;
> > > + struct ec_response_get_cmd_versions resp;
> > > + };
> > > + } __packed buf = {
> > > + .msg = {
> > > + .command = EC_CMD_GET_CMD_VERSIONS +
> > > cmd_offset,
> > > + .insize = sizeof(struct
> > > ec_response_get_cmd_versions),
> > > + .outsize = sizeof(struct
> > > ec_params_get_cmd_versions)
> > > + },
> > > + .params = {.cmd = cmd}
> > > + };
> > > +
> > > + ret = cros_ec_cmd_xfer_status(ec_dev, );
> > > + if (ret >= 0)
> > > + *mask = buf.resp.version_mask;
> > > + return ret;
> > > +}
> > > +
> > > int cros_ec_sensors_core_init(struct platform_device *pdev,
> > > struct iio_dev *indio_dev,
> > > bool physical_device)
> > > @@ -33,6 +58,8 @@ int cros_ec_sensors_core_init(struct
> > > platform_device *pdev,
> > > struct cros_ec_sensors_core_state *state = iio_priv(indio_dev);
> > > struct cros_ec_dev *ec = dev_get_drvdata(pdev->dev.parent);
> > > struct cros_ec_sensor_platform *sensor_platform =
> > > dev_get_platdata(dev);
> > > + u32 ver_mask;
> > > + int ret;
> > >
> > > platform_set_drvdata(pdev, indio_dev);
> > >
> > > @@ -47,8 +74,15 @@ int cros_ec_sensors_core_init(struct
> > > platform_device *pdev,
> > >
> > > mutex_init(>cmd_lock);
> > >
> > > + ret = cros_ec_get_host_cmd_version_mask(state->ec,
> > > + ec->cmd_offset,
> > > + EC_CMD_MOTION_SENSE_CMD
> > > ,
> > > + _mask);
> > > + if (ret < 0)
> > > + return ret;
> > > +
> > > /* Set up the host command structure. */
> > > - state->msg->version = 2;
> > > + state->msg->version = fls(ver_mask) - 1;
> > > state->msg->command = EC_CMD_MOTION_SENSE_CMD + ec->cmd_offset;
> > > state->msg->outsize = sizeof(struct ec_params_motion_sense);
> > >
>
Re: [PATCH] iio: cros_ec: Remove replacing error code with -EIO
On Sun, 21 Jul 2019 18:40:09 +0100
Jonathan Cameron wrote:
> On Thu, 18 Jul 2019 15:22:37 -0700
> Gwendal Grignou wrote:
>
> > Due to an API misread, error code can be different for -EIO when reading
> > a sysfs entry. Return the error reported by the cros_ec stack.
> >
> > Check the proper error message (protocol error, not supported) is
> > reported when there is an error returned by the EC stack.
> >
> > Signed-off-by: Gwendal Grignou
> Hi Gwendal,
>
> If you are going to send a series of small patches for a driver
> and they will inherently cause fuzz for each other, please just
> have a small series called something like "misc fixes".
>
> I clearly applied these in a different order to you, so needed
> a bit of fixing up. I think I got it right, but please check.
>
> Applied to the togreg branch of iio.git and pushed out as testing
> for the autobuilders to play with it.
I did mess this up it seems, but only noticed on a later series.
I just fixed it up, but one case failed to get converted.
Thanks,
Jonathan
>
> Thanks,
>
> Jonathan
>
> > ---
> >
> > .../cros_ec_sensors/cros_ec_sensors_core.c| 44 +++
> > drivers/iio/light/cros_ec_light_prox.c| 36 +++
> > drivers/iio/pressure/cros_ec_baro.c | 17 ---
> > 3 files changed, 51 insertions(+), 46 deletions(-)
> >
> > diff --git a/drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c
> > b/drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c
> > index 130362ca421b..ed29ac22dff8 100644
> > --- a/drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c
> > +++ b/drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c
> > @@ -33,6 +33,7 @@ int cros_ec_sensors_core_init(struct platform_device
> > *pdev,
> > struct cros_ec_sensors_core_state *state = iio_priv(indio_dev);
> > struct cros_ec_dev *ec = dev_get_drvdata(pdev->dev.parent);
> > struct cros_ec_sensor_platform *sensor_platform = dev_get_platdata(dev);
> > + int ret;
> >
> > platform_set_drvdata(pdev, indio_dev);
> >
> > @@ -60,9 +61,10 @@ int cros_ec_sensors_core_init(struct platform_device
> > *pdev,
> >
> > state->param.cmd = MOTIONSENSE_CMD_INFO;
> > state->param.info.sensor_num = sensor_platform->sensor_num;
> > - if (cros_ec_motion_send_host_cmd(state, 0)) {
> > + ret = cros_ec_motion_send_host_cmd(state, 0);
> > + if (ret) {
> > dev_warn(dev, "Can not access sensor info\n");
> > - return -EIO;
> > + return ret;
> > }
> > state->type = state->resp->info.type;
> > state->loc = state->resp->info.location;
> > @@ -86,7 +88,7 @@ int cros_ec_motion_send_host_cmd(struct
> > cros_ec_sensors_core_state *state,
> >
> > ret = cros_ec_cmd_xfer_status(state->ec, state->msg);
> > if (ret < 0)
> > - return -EIO;
> > + return ret;
> >
> > if (ret &&
> > state->resp != (struct ec_response_motion_sense *)state->msg->data)
> > @@ -396,7 +398,7 @@ int cros_ec_sensors_core_read(struct
> > cros_ec_sensors_core_state *st,
> > struct iio_chan_spec const *chan,
> > int *val, int *val2, long mask)
> > {
> > - int ret = IIO_VAL_INT;
> > + int ret;
> >
> > switch (mask) {
> > case IIO_CHAN_INFO_SAMP_FREQ:
> > @@ -404,22 +406,27 @@ int cros_ec_sensors_core_read(struct
> > cros_ec_sensors_core_state *st,
> > st->param.ec_rate.data =
> > EC_MOTION_SENSE_NO_VALUE;
> >
> > - if (cros_ec_motion_send_host_cmd(st, 0))
> > - ret = -EIO;
> > - else
> > - *val = st->resp->ec_rate.ret;
> > + ret = cros_ec_motion_send_host_cmd(st, 0);
> > + if (ret)
> > + break;
> > +
> > + *val = st->resp->ec_rate.ret;
> > + ret = IIO_VAL_INT;
> > break;
> > case IIO_CHAN_INFO_FREQUENCY:
> > st->param.cmd = MOTIONSENSE_CMD_SENSOR_ODR;
> > st->param.sensor_odr.data =
> > EC_MOTION_SENSE_NO_VALUE;
> >
> > - if (cros_ec_motion_send_host_cmd(st, 0))
> > - ret = -EIO;
> > - else
> > - *val = st->resp->sensor_odr.ret;
> > + ret = cros_ec_motion_send_host_cmd(st, 0);
> > + if (ret)
> > + break;
> > +
> > + *val = st->resp->sensor_odr.ret;
> > + ret = IIO_VAL_INT;
> > break;
> > default:
> > + ret = -EINVAL;
> > break;
> > }
> >
> > @@ -431,7 +438,7 @@ int cros_ec_sensors_core_write(struct
> > cros_ec_sensors_core_state *st,
> >struct iio_chan_spec const *chan,
> >int val, int val2, long mask)
> > {
> > - int ret = 0;
> > + int ret;
> >
> > switch (mask) {
> > case
Re: [5.2 REGRESSION] Generic vDSO breaks seccomp-enabled userspace on i386
On Sat, 27 Jul 2019, Thomas Gleixner wrote:
> On Sat, 27 Jul 2019, Andy Lutomirski wrote:
> >
> > I think it's getting quite late to start inventing new seccomp
> > features to fix this. I think the right solution for 5.3 is to change
> > the 32-bit vdso fallback to use the old clock_gettime, i.e.
> > clock_gettime32. This is obviously not an acceptable long-term
> > solution.
>
> Sigh. I'll have a look
Completely untested patch below.
For the record: I have to say that I hate it.
Just to be clear. Once a clever seccomp admin decides to enforce Y2038
compliance by filtering out the legacy syscalls this will force glibc into
the syscall slowpath directly because __vdso_clock_gettime64() is gone.
So this needs a proper secccomp solution soener than later.
The fallback change to the legacy syscall is on purpose conditional on
CONFIG_SECCOMP so those people who care can get access to
__vdso_clock_gettime64() nevertheless.
Thanks,
tglx
8<-
--- a/arch/x86/entry/vdso/vdso32/vdso32.lds.S
+++ b/arch/x86/entry/vdso/vdso32/vdso32.lds.S
@@ -27,7 +27,9 @@ VERSION
__vdso_gettimeofday;
__vdso_time;
__vdso_clock_getres;
+#ifndef CONFIG_SECCOMP
__vdso_clock_gettime64;
+#endif
};
LINUX_2.5 {
--- a/arch/x86/include/asm/vdso/gettimeofday.h
+++ b/arch/x86/include/asm/vdso/gettimeofday.h
@@ -101,6 +101,7 @@ long clock_gettime_fallback(clockid_t _c
{
long ret;
+#ifndef CONFIG_SECCOMP
asm (
"mov %%ebx, %%edx \n"
"mov %[clock], %%ebx \n"
@@ -110,6 +111,36 @@ long clock_gettime_fallback(clockid_t _c
: "0" (__NR_clock_gettime64), [clock] "g" (_clkid), "c" (_ts)
: "edx");
+#else
+ struct old_timespec32 tmpts;
+
+ /*
+* Using clock_gettime and not clock_gettime64 here is a
+* temporary workaround to pacify seccomp filters which are
+* unaware of the Y2038 safe variant.
+*/
+
+ asm (
+ "mov %%ebx, %%edx \n"
+ "mov %[clock], %%ebx \n"
+ "call __kernel_vsyscall \n"
+ "mov %%edx, %%ebx \n"
+ : "=a" (ret), "=m" (tmpts)
+ : "0" (__NR_clock_gettime), [clock] "g" (_clkid), "c" ()
+ : "edx");
+
+ /*
+* The core code will have to convert that back. A smart compiler
+* should notice and avoid the double conversion. If not, bad luck;
+* we we are not going to change the core code just to make seccomp
+* happy.
+*/
+
+ if (!ret) {
+ _ts->tv_sec = tmpts.tv_sec;
+ _ts->tv_nsec = tmpts.tv_nsec;
+ }
+#endif
return ret;
}
@@ -136,6 +167,7 @@ clock_getres_fallback(clockid_t _clkid,
{
long ret;
+#ifndef CONFIG_SECCOMP
asm (
"mov %%ebx, %%edx \n"
"mov %[clock], %%ebx \n"
@@ -144,7 +176,32 @@ clock_getres_fallback(clockid_t _clkid,
: "=a" (ret), "=m" (*_ts)
: "0" (__NR_clock_getres_time64), [clock] "g" (_clkid), "c"
(_ts)
: "edx");
+#else
+ struct old_timespec32 tmpts;
+
+ /*
+* Using clock_getres and not clock_getres_time64 here is a
+* temporary workaround to pacify seccomp filters which are unaware
+* of the time64 variants. Technically there is no requirement to
+* use the 64bit variant here as the resolution is definitely not
+* affected by Y2038, but the end goal of Y2038 is to utilize the
+* new 64bit timespec variants for everything.
+*/
+
+ asm (
+ "mov %%ebx, %%edx \n"
+ "mov %[clock], %%ebx \n"
+ "call __kernel_vsyscall \n"
+ "mov %%edx, %%ebx \n"
+ : "=a" (ret), "=m" (tmpts)
+ : "0" (__NR_clock_getres), [clock] "g" (_clkid), "c" ()
+ : "edx");
+ if (!ret) {
+ _ts->tv_sec = tmpts.tv_sec;
+ _ts->tv_nsec = tmpts.tv_nsec;
+ }
+#endif
return ret;
}
Re: [PATCH] gigaset: stop maintaining seperately
From: Paul Bolle Date: Sat, 27 Jul 2019 00:05:41 +0200 > The Dutch consumer grade ISDN network will be shut down on September 1, > 2019. This means I'll be converted to some sort of VOIP shortly. At that > point it would be unwise to try to maintain the gigaset driver, even for > odd fixes as I do. So I'll stop maintaining it as a seperate driver and > bump support to CAPI in staging. De facto this means the driver will be > unmaintained, since no-one seems to be working on CAPI. > > I've lighty tested the hardware specific modules of this driver (bas-gigaset, > ser-gigaset, and usb-gigaset) for v5.3-rc1. The basic functionality appears to > be working. It's unclear whether anyone still cares. I'm aware of only one > person sort of using the driver a few years ago. > > Thanks to Karsten Keil for the ISDN subsystems gigaset was using (I4L and > CAPI). And many thanks to Hansjoerg Lipp and Tilman Schmidt for writing and > upstreaming this driver. > > Signed-off-by: Paul Bolle Applied.
Re: [PATCH v2] counter/ftm-quaddec: Use device-managed registration API
On Fri, 26 Jul 2019 21:39:16 +0800
Chuhong Yuan wrote:
> Make use of devm_counter_register.
> Then we can remove redundant unregistration API
> usage to make code simpler.
>
> Signed-off-by: Chuhong Yuan
Applied to the togreg branch of iio.git and pushed out as testing
for the autobuilders to play with it.
Thanks,
Jonathan
> ---
> Changes in v2:
> - Use devm_add_action_or_reset to keep
> resource release order.
> - remove() function is redundant now,
> delete it.
>
> drivers/counter/ftm-quaddec.c | 30 --
> 1 file changed, 12 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/counter/ftm-quaddec.c b/drivers/counter/ftm-quaddec.c
> index 68a9b7393457..4046aa9f9234 100644
> --- a/drivers/counter/ftm-quaddec.c
> +++ b/drivers/counter/ftm-quaddec.c
> @@ -100,16 +100,18 @@ static void ftm_quaddec_init(struct ftm_quaddec *ftm)
> ftm_set_write_protection(ftm);
> }
>
> -static void ftm_quaddec_disable(struct ftm_quaddec *ftm)
> +static void ftm_quaddec_disable(void *ftm)
> {
> - ftm_clear_write_protection(ftm);
> - ftm_write(ftm, FTM_MODE, 0);
> - ftm_write(ftm, FTM_QDCTRL, 0);
> + struct ftm_quaddec *ftm_qua = ftm;
> +
> + ftm_clear_write_protection(ftm_qua);
> + ftm_write(ftm_qua, FTM_MODE, 0);
> + ftm_write(ftm_qua, FTM_QDCTRL, 0);
> /*
>* This is enough to disable the counter. No clock has been
>* selected by writing to FTM_SC in init()
>*/
> - ftm_set_write_protection(ftm);
> + ftm_set_write_protection(ftm_qua);
> }
>
> static int ftm_quaddec_get_prescaler(struct counter_device *counter,
> @@ -317,20 +319,13 @@ static int ftm_quaddec_probe(struct platform_device
> *pdev)
>
> ftm_quaddec_init(ftm);
>
> - ret = counter_register(>counter);
> + ret = devm_add_action_or_reset(>dev, ftm_quaddec_disable, ftm);
> if (ret)
> - ftm_quaddec_disable(ftm);
> -
> - return ret;
> -}
> + return ret;
>
> -static int ftm_quaddec_remove(struct platform_device *pdev)
> -{
> - struct ftm_quaddec *ftm = platform_get_drvdata(pdev);
> -
> - counter_unregister(>counter);
> -
> - ftm_quaddec_disable(ftm);
> + ret = devm_counter_register(>dev, >counter);
> + if (ret)
> + return ret;
>
> return 0;
> }
> @@ -346,7 +341,6 @@ static struct platform_driver ftm_quaddec_driver = {
> .of_match_table = ftm_quaddec_match,
> },
> .probe = ftm_quaddec_probe,
> - .remove = ftm_quaddec_remove,
> };
>
> module_platform_driver(ftm_quaddec_driver);
Re: [PATCH 5.2 14/66] net_sched: unset TCQ_F_CAN_BYPASS when adding filters
On Fri, Jul 26, 2019 at 05:24:13PM +0200, Greg Kroah-Hartman wrote:
From: Cong Wang
[ Upstream commit 3f05e6886a595c9a29a309c52f45326be917823c ]
For qdisc's that support TC filters and set TCQ_F_CAN_BYPASS,
notably fq_codel, it makes no sense to let packets bypass the TC
filters we setup in any scenario, otherwise our packets steering
policy could not be enforced.
This can be reproduced easily with the following script:
ip li add dev dummy0 type dummy
ifconfig dummy0 up
tc qd add dev dummy0 root fq_codel
tc filter add dev dummy0 parent 8001: protocol arp basic action mirred egress
redirect dev lo
tc filter add dev dummy0 parent 8001: protocol ip basic action mirred egress
redirect dev lo
ping -I dummy0 192.168.112.1
Without this patch, packets are sent directly to dummy0 without
hitting any of the filters. With this patch, packets are redirected
to loopback as expected.
This fix is not perfect, it only unsets the flag but does not set it back
because we have to save the information somewhere in the qdisc if we
really want that. Note, both fq_codel and sfq clear this flag in their
->bind_tcf() but this is clearly not sufficient when we don't use any
class ID.
Fixes: 23624935e0c4 ("net_sched: TCQ_F_CAN_BYPASS generalization")
Cc: Eric Dumazet
Signed-off-by: Cong Wang
Reviewed-by: Eric Dumazet
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman
There's a fix for this one:
503d81d428bd5 ("net: sched: verify that q!=NULL before setting
q->flags").
--
Thanks,
Sasha
Re: [PATCH 1/2] dt-bindings: iio: avia-hx711: Fix avdd-supply typo in example
On Tue, 16 Jul 2019 14:33:23 -0600
Rob Herring wrote:
> Now that examples are validated against the DT schema, a typo in
> avia-hx711 example generates a warning:
>
> Documentation/devicetree/bindings/iio/adc/avia-hx711.example.dt.yaml: weight:
> 'avdd-supply' is a required property
>
> Fix the typo.
>
> Fixes: 5150ec3fe125 ("avia-hx711.yaml: transform DT binding to YAML")
> Cc: Andreas Klinger
> Cc: Jonathan Cameron
> Cc: linux-...@vger.kernel.org
> Signed-off-by: Rob Herring
> ---
> Jonathan,
>
> I have some other fixes I'm sending to Linus and can take these 2 if
> that's easier.
>
> Rob
Thanks for dealing with these, I missed this thread entirely in my email
whilst travelling / playing catch up.
Jonathan
>
> Documentation/devicetree/bindings/iio/adc/avia-hx711.yaml | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/iio/adc/avia-hx711.yaml
> b/Documentation/devicetree/bindings/iio/adc/avia-hx711.yaml
> index 8a4100ceeaf2..d76ece97c76c 100644
> --- a/Documentation/devicetree/bindings/iio/adc/avia-hx711.yaml
> +++ b/Documentation/devicetree/bindings/iio/adc/avia-hx711.yaml
> @@ -61,6 +61,6 @@ examples:
> compatible = "avia,hx711";
> sck-gpios = < 10 GPIO_ACTIVE_HIGH>;
> dout-gpios = < 7 GPIO_ACTIVE_HIGH>;
> -avdd-suppy = <>;
> +avdd-supply = <>;
> clock-frequency = <10>;
> };
Re: [PATCH] drivers: net: xgene: Move status variable declaration into CONFIG_ACPI block
From: Nathan Chancellor
Date: Fri, 26 Jul 2019 09:20:37 -0700
> When CONFIG_ACPI is unset (arm allyesconfig), status is unused.
>
> drivers/net/ethernet/apm/xgene/xgene_enet_xgmac.c:383:14: warning:
> unused variable 'status' [-Wunused-variable]
> acpi_status status;
> ^
> drivers/net/ethernet/apm/xgene/xgene_enet_sgmac.c:440:14: warning:
> unused variable 'status' [-Wunused-variable]
> acpi_status status;
> ^
> drivers/net/ethernet/apm/xgene/xgene_enet_hw.c:697:14: warning: unused
> variable 'status' [-Wunused-variable]
> acpi_status status;
> ^
>
> Move the declaration into the CONFIG_ACPI block so that there are no
> compiler warnings.
>
> Fixes: 570d785ba46b ("drivers: net: xgene: Remove acpi_has_method() calls")
> Signed-off-by: Nathan Chancellor
Applied.
Re: [PATCH] [v2] iio: adc: gyroadc: fix uninitialized return code
On Thu, 18 Jul 2019 16:02:27 +0200
Wolfram Sang wrote:
> On Thu, Jul 18, 2019 at 03:57:49PM +0200, Arnd Bergmann wrote:
> > gcc-9 complains about a blatant uninitialized variable use that
> > all earlier compiler versions missed:
> >
> > drivers/iio/adc/rcar-gyroadc.c:510:5: warning: 'ret' may be used
> > uninitialized in this function [-Wmaybe-uninitialized]
> >
> > Return -EINVAL instead here and a few lines above it where
> > we accidentally return 0 on failure.
> >
> > Cc: sta...@vger.kernel.org
> > Fixes: 059c53b32329 ("iio: adc: Add Renesas GyroADC driver")
> > Signed-off-by: Arnd Bergmann
>
> Yes, I checked the other error paths, too, and they look proper to me.
>
> Reviewed-by: Wolfram Sang
>
Thanks for sorting that second case as well.
Applied to the fixes-togreg branch of iio.git.
Thanks,
Jonathan
Re: [PATCH] net: rds: Fix possible null-pointer dereferences in rds_rdma_cm_event_handler_cmn()
From: Jia-Ju Bai
Date: Fri, 26 Jul 2019 22:17:05 +0800
> In rds_rdma_cm_event_handler_cmn(), there are some if statements to
> check whether conn is NULL, such as on lines 65, 96 and 112.
> But conn is not checked before being used on line 108:
> trans->cm_connect_complete(conn, event);
> and on lines 140-143:
> rdsdebug("DISCONNECT event - dropping connection "
> "%pI6c->%pI6c\n", >c_laddr,
> >c_faddr);
> rds_conn_drop(conn);
>
> Thus, possible null-pointer dereferences may occur.
>
> To fix these bugs, conn is checked before being used.
>
> These bugs are found by a static analysis tool STCheck written by us.
>
> Signed-off-by: Jia-Ju Bai
Applied.
Re: [PATCH v6 2/2] iio: imu: st_lsm6dsx: add i3c basic support for LSM6DSO and LSM6DSR
On Sat, 27 Jul 2019 12:42:12 +0200 Boris Brezillon wrote: > On Sun, 21 Jul 2019 18:16:56 +0100 > Jonathan Cameron wrote: > > > On Fri, 19 Jul 2019 15:30:55 +0200 > > Vitor Soares wrote: > > > > > For today the st_lsm6dsx driver support LSM6DSO and LSM6DSR sensor only in > > > spi and i2c mode. > > > > > > The LSM6DSO and LSM6DSR are also i3c capable so let's give i3c support to > > > them. > > > > > > Signed-off-by: Vitor Soares > > > Acked-by: Lorenzo Bianconi > > > Reviewed-by: Boris Brezillon > > Great. I'll pick this up once Boris has that immutable branch > > available. Give me a poke if I seem to have lost it! > > Here it is: > Great. Merged that into the togreg branch of iio and applied this patch. Pushed out as testing to let the autobuilders have a poke at it all. Thanks, Jonathan > The following changes since commit 5f9e832c137075045d15cd6899ab0505cfb2ca4b: > > Linus 5.3-rc1 (2019-07-21 14:05:38 -0700) > > are available in the Git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/i3c/linux.git > tags/i3c/export-i3c_device_match_id > > for you to fetch changes up to 934d24a5e1508e73c0001afb54a3916e4270428f: > > i3c: move i3c_device_match_id to device.c and export it (2019-07-27 > 11:22:19 +0200) > > > Needed for the st_lsm6dsx_i3c.c driver > > > Vitor Soares (1): > i3c: move i3c_device_match_id to device.c and export it > > drivers/i3c/device.c | 53 > + > drivers/i3c/master.c | 45 - > include/linux/i3c/device.h | 4 > 3 files changed, 57 insertions(+), 45 deletions(-) > >
Re: [PATCH v2] iio: potentiometer: add a driver for Maxim 5432-5435
On Tue, 23 Jul 2019 10:53:24 +0200
Martin Kaiser wrote:
> Add a driver for the Maxim Integrated MAX5432-MAX5435 family of digital
> potentiometers.
>
> These potentiometers are connected via I2C and have 32 wiper positions.
>
> Supported functionality
> - set the volatile wiper position
> - read the potentiometer scale
>
> Datasheet:
> https://datasheets.maximintegrated.com/en/ds/MAX5432-MAX5435.pdf
>
> Signed-off-by: Martin Kaiser
A few trivials and I'm afraid you posted after I'd made the decision to only
accept new DT bindings for IIO in yaml format.
Thanks,
Jonathan
> ---
> changes in v2
> - use MAX5432_ prefix for all defines
> - fix indentation
> - convert void * to unsigned long, not to u32
>(warning from kbuild test robot)
>
> .../bindings/iio/potentiometer/max5432.txt | 21
> drivers/iio/potentiometer/Kconfig | 11 ++
> drivers/iio/potentiometer/Makefile | 1 +
> drivers/iio/potentiometer/max5432.c| 135
> +
> 4 files changed, 168 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/iio/potentiometer/max5432.txt
> create mode 100644 drivers/iio/potentiometer/max5432.c
>
> diff --git a/Documentation/devicetree/bindings/iio/potentiometer/max5432.txt
> b/Documentation/devicetree/bindings/iio/potentiometer/max5432.txt
> new file mode 100644
> index ..6c6ce85e4c85
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/potentiometer/max5432.txt
We have made the move to yaml for all new IIO related bindings.
Please convert this one over. Also, all bindings should be in
separate patches and CC the devicetree binding maintainers and list.
This just makes them easier for them to pick out and review - shouldn't
be a problem here given it's really simple :)
> @@ -0,0 +1,21 @@
> +* Maxim Integrated MAX5432-MAX5435 Digital Potentiometers.
> +
> +The node for this driver must be a child node of an I2C controller, hence
> +all mandatory properties for your controller must be specified. See
> directory:
> +
> +Documentation/devicetree/bindings/i2c
> +
> +for more details.
> +
> +Required properties:
> +- compatible: Must be one of the following, depending on the model:
> +"maxim,max5432"
> +"maxim,max5433"
> +"maxim,max5434"
> +"maxim,max5435"
> +
> +Example:
> +max5434@28 {
> + compatible = "maxim,max5434";
> + reg = <0x28>;
> +};
> diff --git a/drivers/iio/potentiometer/Kconfig
> b/drivers/iio/potentiometer/Kconfig
> index ebc7c72a5e36..4cac0173db8b 100644
> --- a/drivers/iio/potentiometer/Kconfig
> +++ b/drivers/iio/potentiometer/Kconfig
> @@ -26,6 +26,17 @@ config DS1803
> To compile this driver as a module, choose M here: the
> module will be called ds1803.
>
> +config MAX5432
> + tristate "Maxim MAX5432-MAX5435 Digital Potentiometer driver"
> + depends on I2C
> + help
> + Say yes here to build support for the Maxim
> + MAX5432, MAX5433, MAX5434 and MAX5435 digital
> + potentiometer chips.
> +
> + To compile this driver as a module, choose M here: the
> + module will be called max5432.
> +
> config MAX5481
> tristate "Maxim MAX5481-MAX5484 Digital Potentiometer driver"
> depends on SPI
> diff --git a/drivers/iio/potentiometer/Makefile
> b/drivers/iio/potentiometer/Makefile
> index 8ff55138cf12..091adf3cdd0b 100644
> --- a/drivers/iio/potentiometer/Makefile
> +++ b/drivers/iio/potentiometer/Makefile
> @@ -6,6 +6,7 @@
> # When adding new entries keep the list in alphabetical order
> obj-$(CONFIG_AD5272) += ad5272.o
> obj-$(CONFIG_DS1803) += ds1803.o
> +obj-$(CONFIG_MAX5432) += max5432.o
> obj-$(CONFIG_MAX5481) += max5481.o
> obj-$(CONFIG_MAX5487) += max5487.o
> obj-$(CONFIG_MCP4018) += mcp4018.o
> diff --git a/drivers/iio/potentiometer/max5432.c
> b/drivers/iio/potentiometer/max5432.c
> new file mode 100644
> index ..95251e7c0c34
> --- /dev/null
> +++ b/drivers/iio/potentiometer/max5432.c
> @@ -0,0 +1,135 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * Maxim Integrated MAX5432-MAX5435 digital potentiometer driver
> + * Copyright (C) 2019 Martin Kaiser
> + *
> + * Datasheet:
> + * https://datasheets.maximintegrated.com/en/ds/MAX5432-MAX5435.pdf
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +/* All chip variants have 32 wiper positions. */
> +#define MAX5432_MAX_POS 31
> +
> +#define MAX5432_OHM_50K (50 * 1000)
> +#define MAX5432_OHM_100K (100 * 1000)
> +
> +/* Update the volatile (currently active) setting. */
> +#define MAX5432_CMD_VREG 0x11
> +
> +struct max5432_data {
> + struct i2c_client *client;
> + unsigned long ohm;
> +};
> +
> +static const struct iio_chan_spec max5432_channels[] = {
> + {
> + .type = IIO_RESISTANCE,
> + .indexed = 1,
> + .output = 1,
> + .channel = 0,
> + .address =
Re: [PATCH] net: neigh: remove redundant assignment to variable bucket
From: Colin King
Date: Fri, 26 Jul 2019 10:46:11 +0100
> From: Colin Ian King
>
> The variable bucket is being initialized with a value that is never
> read and it is being updated later with a new value in a following
> for-loop. The initialization is redundant and can be removed.
>
> Addresses-Coverity: ("Unused value")
> Signed-off-by: Colin Ian King
Applied to net-next.
Re: [PATCH] isdn: mISDN: hfcsusb: Fix possible null-pointer dereferences in start_isoc_chain()
From: Jia-Ju Bai Date: Fri, 26 Jul 2019 16:27:36 +0800 > In start_isoc_chain(), usb_alloc_urb() on line 1392 may fail > and return NULL. At this time, fifo->iso[i].urb is assigned to NULL. > > Then, fifo->iso[i].urb is used at some places, such as: > LINE 1405:fill_isoc_urb(fifo->iso[i].urb, ...) > urb->number_of_packets = num_packets; > urb->transfer_flags = URB_ISO_ASAP; > urb->actual_length = 0; > urb->interval = interval; > LINE 1416:fifo->iso[i].urb->... > LINE 1419:fifo->iso[i].urb->... > > Thus, possible null-pointer dereferences may occur. > > To fix these bugs, "continue" is added to avoid using fifo->iso[i].urb > when it is NULL. > > These bugs are found by a static analysis tool STCheck written by us. > > Signed-off-by: Jia-Ju Bai Applied.
Re: [PATCH 2/2] net: ipv6: Fix a possible null-pointer dereference in vti6_link_config()
From: Jia-Ju Bai
Date: Fri, 26 Jul 2019 16:03:21 +0800
> @@ -646,9 +646,10 @@ static void vti6_link_config(struct ip6_tnl *t, bool
> keep_mtu)
>>raddr, >laddr,
>p->link, NULL, strict);
>
> - if (rt)
> + if (rt) {
> tdev = rt->dst.dev;
> - ip6_rt_put(rt);
> + ip6_rt_put(rt);
> + }
ip6_rt_put() can take a NULL argument without any problem.
I want to make it clear that because of mistakes of this nature, and
how frequently you make them, it is very tiring and exhausting to
review your changes...
Re: [PATCH 1/2] net: ipv4: Fix a possible null-pointer dereference in inet_csk_rebuild_route()
From: Jia-Ju Bai Date: Fri, 26 Jul 2019 10:25:34 +0800 > diff --git a/net/ipv4/inet_connection_sock.c b/net/ipv4/inet_connection_sock.c > index f5c163d4771b..27d9d80f3401 100644 > --- a/net/ipv4/inet_connection_sock.c > +++ b/net/ipv4/inet_connection_sock.c > @@ -1073,7 +1073,10 @@ static struct dst_entry *inet_csk_rebuild_route(struct > sock *sk, struct flowi *f > sk_setup_caps(sk, >dst); > rcu_read_unlock(); > > - return >dst; > + if (rt) > + return >dst; > + else > + return NULL; If rt is NULL, >dst is also NULL as has been pointed out to you. Please fix your automated tools to understand this case before submitting more changes. Thank you.
Re: [PATCH net] mvpp2: refactor MTU change code
From: Matteo Croce Date: Fri, 26 Jul 2019 01:19:31 +0200 > The MTU change code can call napi_disable() with the device already down, > leading to a deadlock. Also, lot of code is duplicated unnecessarily. > > Rework mvpp2_change_mtu() to avoid the deadlock and remove duplicated code. > > Signed-off-by: Matteo Croce Please resubmit with the Fixes: tag. Please do not line break the Fixes: tag no matter how many characters it ends up being in total. Thanks.
Re: [PATCH net-next] mvpp2: document HW checksum behaviour
From: Matteo Croce Date: Fri, 26 Jul 2019 16:35:59 +0200 > I see, there is a similar statement in mvpp2_port_probe(). > What about adding a static function which sets the flag, and add the > comment there instead of duplicating the comment? That sounds good to me.
Re: [PATCH 0/2] Make ipmr queue length configurable
From: Brodie Greenfield Date: Fri, 26 Jul 2019 08:42:28 +1200 > We want to have some more space in our queue for processing incoming > multicast packets, so we can process more of them without dropping > them prematurely. It is useful to be able to increase this limit on > higher-spec platforms that can handle more items. > > For the particular use case here at Allied Telesis, we have linux > running on our switches and routers, with support for the number of > multicast groups being increased. Basically, this queue length affects > the time taken to fully learn all of the multicast streams. > > Changes in v3: > - Corrected a v4 to v6 typo. As others have voiced, I think it's dangerous to let every netns increase this so readily. We need to either put in a non-initns limit or simply not allow non-init namespaces to change this. But really socket queue limits are a better place to enforce this.
Re: [PATCH 5/6] clk: imx8mq: Remove CLK_IS_CRITICAL flag for IMX8MQ_CLK_TMU_ROOT
Hi Guido, On Sat, Jul 27, 2019 at 3:26 PM Guido Günther wrote: > I noticed a boot hang yesterday on next-20190726 when loading the > qoriq_thermal which I worked around by blacklisting it. The > fsl,imx8mq-tmu node specifies a clock (IMX8MQ_CLK_TMU_ROOT) but does not > seem to enable, shouldn't it do so? Yes, I think you are right. I don't have access to a imx8mq board at the moment, but something like below would probably help: http://code.bulix.org/pd88jp-812381 If it helps, I can send it as a formal patch. Regards, Fabio Estevam
Re: [PATCH net-next] net: dsa: mv88e6xxx: avoid some redundant vtu load/purge operations
Reminder that we need a review from Vivien on this. Thanks.
Re: [PATCH] iio: magnetometer: mmc35240: Fix a typo in the name of a constant
On Sun, 21 Jul 2019 23:35:33 +0200 Christophe JAILLET wrote: > Everything is about mmc35240_ except MMC53240_WAIT_SET_RESET (3 and 5 > switched). > > This is likely a typo. Define and use MMC35240_WAIT_SET_RESET instead. > > Signed-off-by: Christophe JAILLET Applied to the togreg branch of iio.git and pushed out as testing for the autobuilders to see what we missed. Thanks, Jonathan > --- > drivers/iio/magnetometer/mmc35240.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/iio/magnetometer/mmc35240.c > b/drivers/iio/magnetometer/mmc35240.c > index 7de10281ad9e..425cdd07b4e5 100644 > --- a/drivers/iio/magnetometer/mmc35240.c > +++ b/drivers/iio/magnetometer/mmc35240.c > @@ -53,7 +53,7 @@ > #define MMC35240_CTRL1_BW_SHIFT 0 > > #define MMC35240_WAIT_CHARGE_PUMP5 /* us */ > -#define MMC53240_WAIT_SET_RESET 1000/* us */ > +#define MMC35240_WAIT_SET_RESET 1000/* us */ > > /* > * Memsic OTP process code piece is put here for reference: > @@ -225,7 +225,7 @@ static int mmc35240_init(struct mmc35240_data *data) > ret = mmc35240_hw_set(data, true); > if (ret < 0) > return ret; > - usleep_range(MMC53240_WAIT_SET_RESET, MMC53240_WAIT_SET_RESET + 1); > + usleep_range(MMC35240_WAIT_SET_RESET, MMC35240_WAIT_SET_RESET + 1); > > ret = mmc35240_hw_set(data, false); > if (ret < 0)
[PATCH v2 3/3] IIO: Ingenic JZ47xx: Add support for JZ4770 SoC ADC.
Add support for the ADC hardware present on Ingenic JZ4770 SoC.
Signed-off-by: Artur Rojek
Tested-by: Paul Cercueil
---
Changes:
v2: - move the IIO_CHAN_INFO_RAW block into a utility function,
- unconditionally lock aux_lock for reduced complexity
drivers/iio/adc/ingenic-adc.c | 149 +-
1 file changed, 127 insertions(+), 22 deletions(-)
diff --git a/drivers/iio/adc/ingenic-adc.c b/drivers/iio/adc/ingenic-adc.c
index e234970b7150..7a53c2f8d438 100644
--- a/drivers/iio/adc/ingenic-adc.c
+++ b/drivers/iio/adc/ingenic-adc.c
@@ -25,9 +25,13 @@
#define JZ_ADC_REG_ADSDAT 0x20
#define JZ_ADC_REG_ADCLK 0x28
+#define JZ_ADC_REG_ENABLE_PD BIT(7)
+#define JZ_ADC_REG_CFG_AUX_MD (BIT(0) | BIT(1))
#define JZ_ADC_REG_CFG_BAT_MD BIT(4)
#define JZ_ADC_REG_ADCLK_CLKDIV_LSB0
-#define JZ_ADC_REG_ADCLK_CLKDIV10US_LSB16
+#define JZ4725B_ADC_REG_ADCLK_CLKDIV10US_LSB 16
+#define JZ4770_ADC_REG_ADCLK_CLKDIV10US_LSB8
+#define JZ4770_ADC_REG_ADCLK_CLKDIVMS_LSB 16
#define JZ_ADC_AUX_VREF3300
#define JZ_ADC_AUX_VREF_BITS 12
@@ -37,6 +41,8 @@
#define JZ4725B_ADC_BATTERY_HIGH_VREF_BITS 10
#define JZ4740_ADC_BATTERY_HIGH_VREF (7500 * 0.986)
#define JZ4740_ADC_BATTERY_HIGH_VREF_BITS 12
+#define JZ4770_ADC_BATTERY_VREF6600
+#define JZ4770_ADC_BATTERY_VREF_BITS 12
struct ingenic_adc;
@@ -47,6 +53,8 @@ struct ingenic_adc_soc_data {
size_t battery_raw_avail_size;
const int *battery_scale_avail;
size_t battery_scale_avail_size;
+ unsigned int battery_vref_mode: 1;
+ unsigned int has_aux2: 1;
int (*init_clk_div)(struct device *dev, struct ingenic_adc *adc);
};
@@ -54,6 +62,7 @@ struct ingenic_adc {
void __iomem *base;
struct clk *clk;
struct mutex lock;
+ struct mutex aux_lock;
const struct ingenic_adc_soc_data *soc_data;
bool low_vref_mode;
};
@@ -120,6 +129,8 @@ static int ingenic_adc_write_raw(struct iio_dev *iio_dev,
case IIO_CHAN_INFO_SCALE:
switch (chan->channel) {
case INGENIC_ADC_BATTERY:
+ if (!adc->soc_data->battery_vref_mode)
+ return -EINVAL;
if (val > JZ_ADC_BATTERY_LOW_VREF) {
ingenic_adc_set_config(adc,
JZ_ADC_REG_CFG_BAT_MD,
@@ -158,6 +169,14 @@ static const int jz4740_adc_battery_scale_avail[] = {
JZ_ADC_BATTERY_LOW_VREF, JZ_ADC_BATTERY_LOW_VREF_BITS,
};
+static const int jz4770_adc_battery_raw_avail[] = {
+ 0, 1, (1 << JZ4770_ADC_BATTERY_VREF_BITS) - 1,
+};
+
+static const int jz4770_adc_battery_scale_avail[] = {
+ JZ4770_ADC_BATTERY_VREF, JZ4770_ADC_BATTERY_VREF_BITS,
+};
+
static int jz4725b_adc_init_clk_div(struct device *dev, struct ingenic_adc
*adc)
{
struct clk *parent_clk;
@@ -187,7 +206,45 @@ static int jz4725b_adc_init_clk_div(struct device *dev,
struct ingenic_adc *adc)
/* We also need a divider that produces a 10us clock. */
div_10us = DIV_ROUND_UP(rate, 10);
- writel(((div_10us - 1) << JZ_ADC_REG_ADCLK_CLKDIV10US_LSB) |
+ writel(((div_10us - 1) << JZ4725B_ADC_REG_ADCLK_CLKDIV10US_LSB) |
+ (div_main - 1) << JZ_ADC_REG_ADCLK_CLKDIV_LSB,
+ adc->base + JZ_ADC_REG_ADCLK);
+
+ return 0;
+}
+
+static int jz4770_adc_init_clk_div(struct device *dev, struct ingenic_adc *adc)
+{
+ struct clk *parent_clk;
+ unsigned long parent_rate, rate;
+ unsigned int div_main, div_ms, div_10us;
+
+ parent_clk = clk_get_parent(adc->clk);
+ if (!parent_clk) {
+ dev_err(dev, "ADC clock has no parent\n");
+ return -ENODEV;
+ }
+ parent_rate = clk_get_rate(parent_clk);
+
+ /*
+* The JZ4770 ADC works at 20 kHz to 200 kHz.
+* We pick the highest rate possible.
+*/
+ div_main = DIV_ROUND_UP(parent_rate, 20);
+ div_main = clamp(div_main, 1u, 256u);
+ rate = parent_rate / div_main;
+ if (rate < 2 || rate > 20) {
+ dev_err(dev, "No valid divider for ADC main clock\n");
+ return -EINVAL;
+ }
+
+ /* We also need a divider that produces a 10us clock. */
+ div_10us = DIV_ROUND_UP(rate, 1);
+ /* And another, which produces a 1ms clock. */
+ div_ms = DIV_ROUND_UP(rate, 1000);
+
+ writel(((div_ms - 1) << JZ4770_ADC_REG_ADCLK_CLKDIVMS_LSB) |
+ ((div_10us - 1) << JZ4770_ADC_REG_ADCLK_CLKDIV10US_LSB) |
(div_main - 1) << JZ_ADC_REG_ADCLK_CLKDIV_LSB,
adc->base + JZ_ADC_REG_ADCLK);
@@ -201,6 +258,8 @@ static const struct ingenic_adc_soc_data
jz4725b_adc_soc_data = {
[PATCH v2 1/3] dt-bindings: iio/adc: Add a compatible string for JZ4770 SoC ADC
Add a compatible string for the ADC controller present on Ingenic JZ4770 SoC. Signed-off-by: Artur Rojek Reviewed-by: Rob Herring --- Changes: v2: no change Documentation/devicetree/bindings/iio/adc/ingenic,adc.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/iio/adc/ingenic,adc.txt b/Documentation/devicetree/bindings/iio/adc/ingenic,adc.txt index f01159f20d87..cd9048cf9dcf 100644 --- a/Documentation/devicetree/bindings/iio/adc/ingenic,adc.txt +++ b/Documentation/devicetree/bindings/iio/adc/ingenic,adc.txt @@ -5,6 +5,7 @@ Required properties: - compatible: Should be one of: * ingenic,jz4725b-adc * ingenic,jz4740-adc + * ingenic,jz4770-adc - reg: ADC controller registers location and length. - clocks: phandle to the SoC's ADC clock. - clock-names: Must be set to "adc". -- 2.22.0
[PATCH v2 2/3] dt-bindings: iio/adc: Add AUX2 channel idx for JZ4770 SoC ADC
Introduce support for AUX2 channel found in ADC hardware present on Ingenic JZ4770 SoC. Signed-off-by: Artur Rojek Reviewed-by: Rob Herring --- Changes: v2: no change include/dt-bindings/iio/adc/ingenic,adc.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/dt-bindings/iio/adc/ingenic,adc.h b/include/dt-bindings/iio/adc/ingenic,adc.h index 82706b2706ac..42f871ab3272 100644 --- a/include/dt-bindings/iio/adc/ingenic,adc.h +++ b/include/dt-bindings/iio/adc/ingenic,adc.h @@ -6,5 +6,6 @@ /* ADC channel idx. */ #define INGENIC_ADC_AUX0 #define INGENIC_ADC_BATTERY1 +#define INGENIC_ADC_AUX2 2 #endif -- 2.22.0
Re: [PATCH 2/3] iio: light: veml6070: convert to i2c_new_dummy_device
On Mon, 22 Jul 2019 19:26:12 +0200
Wolfram Sang wrote:
> Move from i2c_new_dummy() to i2c_new_dummy_device(), so we now get an
> ERRPTR which we use in error handling.
>
> Signed-off-by: Wolfram Sang
Applied to the togreg branch of iio.git and pushed out as testing
for the autobuilders to do something random with it.
Thanks,
Jonathan
> ---
>
> Generated with coccinelle. Build tested by me and buildbot. Not tested on HW.
>
> drivers/iio/light/veml6070.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/iio/light/veml6070.c b/drivers/iio/light/veml6070.c
> index a3138e1b5803..0be553ad5989 100644
> --- a/drivers/iio/light/veml6070.c
> +++ b/drivers/iio/light/veml6070.c
> @@ -158,10 +158,10 @@ static int veml6070_probe(struct i2c_client *client,
> indio_dev->name = VEML6070_DRV_NAME;
> indio_dev->modes = INDIO_DIRECT_MODE;
>
> - data->client2 = i2c_new_dummy(client->adapter, VEML6070_ADDR_DATA_LSB);
> - if (!data->client2) {
> + data->client2 = i2c_new_dummy_device(client->adapter,
> VEML6070_ADDR_DATA_LSB);
> + if (IS_ERR(data->client2)) {
> dev_err(>dev, "i2c device for second chip address
> failed\n");
> - return -ENODEV;
> + return PTR_ERR(data->client2);
> }
>
> data->config = VEML6070_IT_10 | VEML6070_COMMAND_RSRVD |
Re: [PATCH 3/3] iio: pressure: hp03: convert to i2c_new_dummy_device
On Mon, 22 Jul 2019 19:26:13 +0200
Wolfram Sang wrote:
> Move from i2c_new_dummy() to i2c_new_dummy_device(), so we now get an
> ERRPTR which we use in error handling.
>
> Signed-off-by: Wolfram Sang
Applied, thanks.
J
> ---
>
> Generated with coccinelle. Build tested by me and buildbot. Not tested on HW.
>
> drivers/iio/pressure/hp03.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/iio/pressure/hp03.c b/drivers/iio/pressure/hp03.c
> index f00102577fd5..026ba15ef68f 100644
> --- a/drivers/iio/pressure/hp03.c
> +++ b/drivers/iio/pressure/hp03.c
> @@ -243,10 +243,10 @@ static int hp03_probe(struct i2c_client *client,
>* which has it's dedicated I2C address and contains
>* the calibration constants for the sensor.
>*/
> - priv->eeprom_client = i2c_new_dummy(client->adapter, HP03_EEPROM_ADDR);
> - if (!priv->eeprom_client) {
> + priv->eeprom_client = i2c_new_dummy_device(client->adapter,
> HP03_EEPROM_ADDR);
> + if (IS_ERR(priv->eeprom_client)) {
> dev_err(dev, "New EEPROM I2C device failed\n");
> - return -ENODEV;
> + return PTR_ERR(priv->eeprom_client);
> }
>
> priv->eeprom_regmap = regmap_init_i2c(priv->eeprom_client,
Re: [PATCH 1/3] iio: light: cm36651: convert to i2c_new_dummy_device
On Mon, 22 Jul 2019 19:26:11 +0200
Wolfram Sang wrote:
> Move from i2c_new_dummy() to i2c_new_dummy_device(), so we now get an
> ERRPTR which we use in error handling.
>
> Signed-off-by: Wolfram Sang
Hi,
Hmm. I've been rather busy recently so the IIO tree is based before this
got introduced.
Meh, it's early in the cycle so I'm just going to rebase and hope it
doesn't cause anyone too much pain. I suspect the number of people
tracking my togreg branch is very small to 0.
Applied to a rebase version of the togreg branch of iio.git and
pushed out as testing for the autobuilders to poke at it.
Thanks,
Jonathan
> ---
>
> Generated with coccinelle. Build tested by me and buildbot. Not tested on HW.
>
> drivers/iio/light/cm36651.c | 12 ++--
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/iio/light/cm36651.c b/drivers/iio/light/cm36651.c
> index 7702c2bcbcfa..1019d625adb1 100644
> --- a/drivers/iio/light/cm36651.c
> +++ b/drivers/iio/light/cm36651.c
> @@ -646,18 +646,18 @@ static int cm36651_probe(struct i2c_client *client,
> i2c_set_clientdata(client, indio_dev);
>
> cm36651->client = client;
> - cm36651->ps_client = i2c_new_dummy(client->adapter,
> + cm36651->ps_client = i2c_new_dummy_device(client->adapter,
>CM36651_I2C_ADDR_PS);
> - if (!cm36651->ps_client) {
> + if (IS_ERR(cm36651->ps_client)) {
> dev_err(>dev, "%s: new i2c device failed\n", __func__);
> - ret = -ENODEV;
> + ret = PTR_ERR(cm36651->ps_client);
> goto error_disable_reg;
> }
>
> - cm36651->ara_client = i2c_new_dummy(client->adapter, CM36651_ARA);
> - if (!cm36651->ara_client) {
> + cm36651->ara_client = i2c_new_dummy_device(client->adapter,
> CM36651_ARA);
> + if (IS_ERR(cm36651->ara_client)) {
> dev_err(>dev, "%s: new i2c device failed\n", __func__);
> - ret = -ENODEV;
> + ret = PTR_ERR(cm36651->ara_client);
> goto error_i2c_unregister_ps;
> }
>
Re: [PATCH 00/12] treewide: Fix GENMASK misuses
Trimming CC-list. > It'd can't be done as it's used in declarations > and included in asm files and it uses the UL() > macro. Can the BUILD_BUG_ON_ZERO() macro be used instead? It works in declarations. I don't know if it works in asm-files, but the below changes builds an x86-64 allyesconfig without problems (after the rest of this series have been applied. /Rikard --- include/linux/bits.h | 9 +++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/include/linux/bits.h b/include/linux/bits.h index 669d69441a62..52e747d27f87 100644 --- a/include/linux/bits.h +++ b/include/linux/bits.h @@ -2,6 +2,7 @@ #ifndef __LINUX_BITS_H #define __LINUX_BITS_H +#include #include #include @@ -19,11 +20,15 @@ * GENMASK_ULL(39, 21) gives us the 64bit vector 0x00e0. */ #define GENMASK(h, l) \ + (BUILD_BUG_ON_ZERO(__builtin_choose_expr( \ + __is_constexpr(h) && __is_constexpr(l), (l) > (h), 0)) + \ (((~UL(0)) - (UL(1) << (l)) + 1) & \ -(~UL(0) >> (BITS_PER_LONG - 1 - (h +(~UL(0) >> (BITS_PER_LONG - 1 - (h) #define GENMASK_ULL(h, l) \ + (BUILD_BUG_ON_ZERO(__builtin_choose_expr( \ + __is_constexpr(h) && __is_constexpr(l), (l) > (h), 0)) + \ (((~ULL(0)) - (ULL(1) << (l)) + 1) & \ -(~ULL(0) >> (BITS_PER_LONG_LONG - 1 - (h +(~ULL(0) >> (BITS_PER_LONG_LONG - 1 - (h) #endif /* __LINUX_BITS_H */ -- 2.22.0
Re: [PATCH 1/4] dt-bindings: counter: new bindings for TI eQEP
On Mon, 22 Jul 2019 10:45:35 -0500
David Lechner wrote:
> This documents device tree binding for the Texas Instruments Enhanced
> Quadrature Encoder Pulse (eQEP) Module found in various TI SoCs.
>
> Signed-off-by: David Lechner
Up to William given it is a counter binding, (unless Rob overrules)
but new bindings are generally preferred as yaml.
Content looks fine to me.
Thanks,
Jonathan
> ---
> .../devicetree/bindings/counter/ti-eqep.txt| 18 ++
> 1 file changed, 18 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/counter/ti-eqep.txt
>
> diff --git a/Documentation/devicetree/bindings/counter/ti-eqep.txt
> b/Documentation/devicetree/bindings/counter/ti-eqep.txt
> new file mode 100644
> index ..fbcebc2c2cc2
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/counter/ti-eqep.txt
> @@ -0,0 +1,18 @@
> +Texas Instruments Enhanced Quadrature Encoder Pulse (eQEP) Module
> +
> +Required properties:
> +- compatible:Must be "ti,am3352-eqep".
> +- reg: Physical base address and size of the registers
> map.
> +- clocks:Handle to the PWM's functional clock.
> +- clock-names: Must be "fck".
> +- interrupts:Handle to the eQEP event interrupt
> +
> +Example:
> +
> + eqep0: eqep@180 {
> + compatible = "ti,am3352-eqep";
> + reg = <0x180 0x80>;
> + clocks = <_gclk>;
> + clock-names = "fck";
> + interrupts = <79>;
> + };
[PATCH 0/2] ARM: dts: meson8b: persistent MAC address for Odroid-C1
This series makes Odroid-C1 use the MAC address which is programmed into the eFuse. build-time dependencies: patches are based on top of "ARM: dts: meson8b: add VDDEE / mali-supply" from [0] runtime dependencies (without these a random MAC address is assigned, just like before these patches): - "nvmem: meson-mx-efuse: allow reading data smaller than word_size" from [1] - "net: stmmac: manage errors returned by of_get_mac_address()" from [2] [0] https://patchwork.kernel.org/cover/11062361/ [1] https://patchwork.kernel.org/patch/11062659/ [2] https://patchwork.kernel.org/patch/11062657/ Martin Blumenstingl (2): ARM: dts: meson8b: add the nvmem cell with the board's MAC address ARM: dts: meson8b: odroidc1: use the MAC address stored in the eFuse arch/arm/boot/dts/meson8b-odroidc1.dts | 3 +++ arch/arm/boot/dts/meson8b.dtsi | 4 2 files changed, 7 insertions(+) -- 2.22.0
[PATCH 1/2] ARM: dts: meson8b: add the nvmem cell with the board's MAC address
Amlogic's BSP kernel defines that all boards with a MAC address stored
in the eFuse have it at offset 0x1b4. It is up to the board to
decide whether to use this MAC address or not:
- Odroid-C1 uses the MAC address from the eFuse
- EC-100 seems to read the MAC address from eMMC
Add the nvmem cell which describes the Ethernet MAC address. Don't
assign it to the Ethernet controller, because depending on the board the
actual MAC address may be read from somewhere else.
Signed-off-by: Martin Blumenstingl
---
arch/arm/boot/dts/meson8b.dtsi | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/meson8b.dtsi b/arch/arm/boot/dts/meson8b.dtsi
index 30fca9bb4bbe..c7de58b71d08 100644
--- a/arch/arm/boot/dts/meson8b.dtsi
+++ b/arch/arm/boot/dts/meson8b.dtsi
@@ -402,6 +402,10 @@
clocks = < CLKID_EFUSE>;
clock-names = "core";
+ ethernet_mac_address: mac@1b4 {
+ reg = <0x1b4 0x6>;
+ };
+
temperature_calib: calib@1f4 {
/* only the upper two bytes are relevant */
reg = <0x1f4 0x4>;
--
2.22.0
[PATCH 2/2] ARM: dts: meson8b: odroidc1: use the MAC address stored in the eFuse
Odroid-C1 (and probably other Meson8b boards which are based on the
reference designs) uses the MAC address stored in eFuse at offset 0x1b4.
Assign the nvmem cell to the Ethernet controller as "mac-address" so the
MAC address which is stored in the eFuse is assigned to the Ethernet
controller. This means the MAC address will be consistent across
reboots.
Signed-off-by: Martin Blumenstingl
---
arch/arm/boot/dts/meson8b-odroidc1.dts | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm/boot/dts/meson8b-odroidc1.dts
b/arch/arm/boot/dts/meson8b-odroidc1.dts
index 90f66dc45115..df428a40a748 100644
--- a/arch/arm/boot/dts/meson8b-odroidc1.dts
+++ b/arch/arm/boot/dts/meson8b-odroidc1.dts
@@ -200,6 +200,9 @@
phy-handle = <_phy>;
amlogic,tx-delay-ns = <4>;
+ nvmem-cells = <_mac_address>;
+ nvmem-cell-names = "mac-address";
+
mdio {
compatible = "snps,dwmac-mdio";
#address-cells = <1>;
--
2.22.0
Re: [PATCH v2 1/2] pidfd: add P_PIDFD to waitid()
On Sat, Jul 27, 2019 at 05:49:32PM +0100, Al Viro wrote: > On Sat, Jul 27, 2019 at 09:28:40AM -0700, Linus Torvalds wrote: > > > is the stupid and straightforward thing, but if you want to be > > *clever* you can actually avoid getting a reference to the 'struct > > file *" entirely, and do the fd->pid lookup under rcu_read_lock() > > instead. It's slightly more complex, but it avoids the fdget/fdput > > reference count games entirely. > > Yecchhh... Please, don't do the last part - at least not unless > we really see that in profiles. Yeah, I will leave this out for now. Christian
Re: [PATCH 0/4] new driver for TI eQEP
On Thu, 25 Jul 2019 17:52:21 -0500 David Lechner wrote: > On 7/25/19 7:40 AM, William Breathitt Gray wrote: > > On Mon, Jul 22, 2019 at 10:45:34AM -0500, David Lechner wrote: > >> This series adds device tree bindings and a new counter driver for the > >> Texas > >> Instruments Enhanced Quadrature Encoder Pulse (eQEP). > >> > >> As mentioned in one of the commit messages, to start with, the driver only > >> supports reading the current counter value and setting the min/max values. > >> Other features can be added on an as-needed basis. > >> > >> The only other feature I am interested in is adding is getting time data in > >> order to calculate the rotational speed of a motor. However, there probably > >> needs to be a higher level discussion of how this can fit into the counter > >> subsystem in general first. > > > > I believe exposing some sort of time data has merit. Quadrature counter > > devices in particular are commonly used for position tracking of > > automation systems, and such systems would benefit from velocity/speed > > information. So let's try to introduce that sort of functionality in this > > driver if possible. > > > > First, let's discuss your specific use case and requirements, and hopefully > > we > > can generalize it enough to be of use for future drivers. From your > > description, > > it sounds like you're attaching some sort of rotary encoder to the eQEP > > device. > > Is that correct? What sort of time data are you hoping to use; does the eQEP > > device provide a clock value, or would you be grabbing a timestamp from the > > system? > > My use case is robotics using LEGO MINDSTORMS. More specifically, I am using > motors that have a cheap optical rotary encoder (plastic wheel and infrared > LED/detectors) that give 360 counts per 1 rotation of the motor shaft. One > count > is defined as the rising edge or falling edge of the A signal. We are looking > at > anywhere from 0 to around 2000 counts per second. We use the speed as > feedback in > a control algorithm to drive the motor at a constant speed. The control loop > updates on the order of 1 to 10 ms. > > Because the encoder resolution and speeds are relatively low, we are currently > logging a timestamp for each count. If no count occurs for 50ms, then we log > the > same count again with a new timestamp (otherwise we would never see 0 speed). > To > get the actual speed, we find the first timestamp > 20 ms before the current > timestamp then compute the speed as the change in position divided by the > change > in time between these two samples. This give a fairly accurate speed across > most > of the range, but does get a bit noisy once we get below 100 counts per > second. > It also means that we need a ring buffer that holds about 50 samples. > > The timestamp itself comes from the eQEP, not the system. There are latching > registers to ensure that the timestamp read is from exactly the moment when > the count register was read. > > > > I'm not sure yet if it would make sense to expose rotational speed directly > > as > > an attribute. If we were to expose just the count value and timestamp since > > the > > last read, that should be enough for a user to compute the delta and derive > > speed. I'll think more about this since some devices may simplify that case > > if > > the hardware is able to compute the speed for us. > > > > I agree that it probably doesn't make sense to expect drivers to compute the > speed. There isn't really a general way to do that works for an arbitrary > speed. For example at high speeds, it is better to just look at the change > in counts over a fixed interval rather than triggering a timestamp based on > a certain number of counts. Worth noting perhaps that userspace has the same problem with knowing the right approach... > > I also don't think having a timestamp sysfs attribute would be very useful. > To make it work at all, I think it would have to be implemented such that > it returns the timestamp for the count that was most recently read via sysfs. > And it would require 4 syscalls (2 seeks and 2 reads) to get a single count/ > timestamp pair in a control loop. On a 300MHz ARM9 processor, this is not > a negligible amount of time. > > I noticed that several of the other counter drivers also register an IIO > device. So this got me thinking that perhaps the counter subsystem should > just be for configuring a counter device an then the IIO subsystem should > be used for triggers and ring buffers. > > For the general case a counter device could have two possible triggers. > One that triggers an interrupt after X counts and another that triggers > with a period of T nanoseconds (or microseconds). Both triggers would add > a count/timestamp pair to an IIO ring buffer. > > To fully reproduce our current methodology the first trigger would actually > need two configurable settings, the count X that triggers every X counts and > a watchdog time
Re: [PATCH v2 1/2] pidfd: add P_PIDFD to waitid()
On Sat, Jul 27, 2019 at 09:28:40AM -0700, Linus Torvalds wrote: > Sorry to keep pestering about the patch series, but with the addition > of P_PIDFD, I react once again.. That's fine. I don't at all mind being particular about how something has to be done as long as the result is functional. In this case it seems we'll end up with something cleaner overall, so sure. I'll rework the snippets into the actual patch and resend. I'll leave out the rcu-cleverness you suggested in the other mail though. Christian
Re: [PATCH v2 1/2] pidfd: add P_PIDFD to waitid()
On Sat, Jul 27, 2019 at 09:41:25AM -0700, Linus Torvalds wrote:
> On Sat, Jul 27, 2019 at 9:28 AM Linus Torvalds
> wrote:
> >
> > Something like
> >
> > struct pid *fd_to_pid(unsigned int fd)
> > {
> > struct fd f;
> > struct pid *pid;
> ...
>
> I forgot to put my usual disclaimer about TOTALLY UNTESTED GARBAGE in
> that email. I want to make that part clear: that code snippet was
> meant as a rough guide of direction, not as a "this works".
>
> Hopefully that was clear.
Yeah. I don't take code someone else has written without verifying or
testing into my own code. And I hope people do the same with mine. :)
Christian
Re: [GIT PULL] Wimplicit-fallthrough patches for 5.3-rc2
On 7/27/19 1:08 PM, Linus Torvalds wrote: > > Ok, I have tried re-pulling and if it passes my build tests cleanly > I'll push the result out. > Awesome. :) Thanks! -- Gustavo
[PATCH v2] nvmem: meson-mx-efuse: allow reading data smaller than word_size
Some Amlogic boards store the Ethernet MAC address inside the eFuse. The Ethernet MAC address uses 6 bytes. The existing logic in meson_mx_efuse_read() would write beyond the end of the data buffer when trying to read data with a size that is not aligned to word_size (4 bytes on Meson8, Meson8b and Meson8m2). Calculate the remaining data to copy inside meson_mx_efuse_read() so reading 6 bytes doesn't write beyond the end of the data buffer. Signed-off-by: Martin Blumenstingl --- Changes since v1: - switch from min() to min_t() to get rid of a compiler warning drivers/nvmem/meson-mx-efuse.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/nvmem/meson-mx-efuse.c b/drivers/nvmem/meson-mx-efuse.c index 2976aef87c82..e8fc0baa09e7 100644 --- a/drivers/nvmem/meson-mx-efuse.c +++ b/drivers/nvmem/meson-mx-efuse.c @@ -155,7 +155,8 @@ static int meson_mx_efuse_read(void *context, unsigned int offset, if (err) break; - memcpy(buf + i, , efuse->config.word_size); + memcpy(buf + i, , + min_t(size_t, bytes - i, efuse->config.word_size)); } meson_mx_efuse_mask_bits(efuse, MESON_MX_EFUSE_CNTL1, -- 2.22.0
[PATCH] net: stmmac: manage errors returned by of_get_mac_address()
Commit d01f449c008a ("of_net: add NVMEM support to of_get_mac_address")
added support for reading the MAC address from an nvmem-cell. This
required changing the logic to return an error pointer upon failure.
If stmmac is loaded before the nvmem provider driver then
of_get_mac_address() return an error pointer with -EPROBE_DEFER.
Propagate this error so the stmmac driver will be probed again after the
nvmem provider driver is loaded.
Default to a random generated MAC address in case of any other error,
instead of using the error pointer as MAC address.
Fixes: d01f449c008a ("of_net: add NVMEM support to of_get_mac_address")
Signed-off-by: Martin Blumenstingl
---
drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
index 73fc2524372e..154daf4d1072 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
@@ -370,6 +370,13 @@ stmmac_probe_config_dt(struct platform_device *pdev, const
char **mac)
return ERR_PTR(-ENOMEM);
*mac = of_get_mac_address(np);
+ if (IS_ERR(*mac)) {
+ if (PTR_ERR(*mac) == -EPROBE_DEFER)
+ return ERR_CAST(*mac);
+
+ *mac = NULL;
+ }
+
plat->interface = of_get_phy_mode(np);
/* Some wrapper drivers still rely on phy_node. Let's save it while
--
2.22.0
[PATCH] nvmem: meson-mx-efuse: allow reading data smaller than word_size
Some Amlogic boards store the Ethernet MAC address inside the eFuse. The Ethernet MAC address uses 6 bytes. The existing logic in meson_mx_efuse_read() would write beyond the end of the data buffer when trying to read data with a size that is not aligned to word_size (4 bytes on Meson8, Meson8b and Meson8m2). Calculate the remaining data to copy inside meson_mx_efuse_read() so reading 6 bytes doesn't write beyond the end of the data buffer. Signed-off-by: Martin Blumenstingl --- drivers/nvmem/meson-mx-efuse.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/nvmem/meson-mx-efuse.c b/drivers/nvmem/meson-mx-efuse.c index 2976aef87c82..d5ccde1abd8e 100644 --- a/drivers/nvmem/meson-mx-efuse.c +++ b/drivers/nvmem/meson-mx-efuse.c @@ -155,7 +155,7 @@ static int meson_mx_efuse_read(void *context, unsigned int offset, if (err) break; - memcpy(buf + i, , efuse->config.word_size); + memcpy(buf + i, , min(bytes - i, efuse->config.word_size)); } meson_mx_efuse_mask_bits(efuse, MESON_MX_EFUSE_CNTL1, -- 2.22.0
[PATCH 2/4] irqchip: ingenic: Error out if IRQ domain creation failed
If we cannot create the IRQ domain, the driver should fail to probe
instead of succeeding with just a warning message.
Signed-off-by: Paul Cercueil
---
drivers/irqchip/irq-ingenic.c | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/drivers/irqchip/irq-ingenic.c b/drivers/irqchip/irq-ingenic.c
index 06fa810e89bb..d97a3a500249 100644
--- a/drivers/irqchip/irq-ingenic.c
+++ b/drivers/irqchip/irq-ingenic.c
@@ -87,6 +87,14 @@ static int __init ingenic_intc_of_init(struct device_node
*node,
goto out_unmap_irq;
}
+ domain = irq_domain_add_legacy(node, num_chips * 32,
+ JZ4740_IRQ_BASE, 0,
+ _domain_simple_ops, NULL);
+ if (!domain) {
+ err = -ENOMEM;
+ goto out_unmap_base;
+ }
+
for (i = 0; i < num_chips; i++) {
/* Mask all irqs */
writel(0x, intc->base + (i * CHIP_SIZE) +
@@ -112,14 +120,11 @@ static int __init ingenic_intc_of_init(struct device_node
*node,
IRQ_NOPROBE | IRQ_LEVEL);
}
- domain = irq_domain_add_legacy(node, num_chips * 32, JZ4740_IRQ_BASE, 0,
- _domain_simple_ops, NULL);
- if (!domain)
- pr_warn("unable to register IRQ domain\n");
-
setup_irq(parent_irq, _cascade_action);
return 0;
+out_unmap_base:
+ iounmap(intc->base);
out_unmap_irq:
irq_dispose_mapping(parent_irq);
out_free:
--
2.21.0.593.g511ec345e18
[PATCH 3/4] irqchip: ingenic: Get virq number from IRQ domain
Get the virq number from the IRQ domain instead of calculating it from
the hardcoded irq base.
Signed-off-by: Paul Cercueil
---
drivers/irqchip/irq-ingenic.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/irqchip/irq-ingenic.c b/drivers/irqchip/irq-ingenic.c
index d97a3a500249..82a079fa3a3d 100644
--- a/drivers/irqchip/irq-ingenic.c
+++ b/drivers/irqchip/irq-ingenic.c
@@ -21,6 +21,7 @@
struct ingenic_intc_data {
void __iomem *base;
+ struct irq_domain *domain;
unsigned num_chips;
};
@@ -34,6 +35,7 @@ struct ingenic_intc_data {
static irqreturn_t intc_cascade(int irq, void *data)
{
struct ingenic_intc_data *intc = irq_get_handler_data(irq);
+ struct irq_domain *domain = intc->domain;
uint32_t irq_reg;
unsigned i;
@@ -43,7 +45,8 @@ static irqreturn_t intc_cascade(int irq, void *data)
if (!irq_reg)
continue;
- generic_handle_irq(__fls(irq_reg) + (i * 32) + JZ4740_IRQ_BASE);
+ irq = irq_find_mapping(domain, __fls(irq_reg) + (i * 32));
+ generic_handle_irq(irq);
}
return IRQ_HANDLED;
@@ -95,6 +98,8 @@ static int __init ingenic_intc_of_init(struct device_node
*node,
goto out_unmap_base;
}
+ intc->domain = domain;
+
for (i = 0; i < num_chips; i++) {
/* Mask all irqs */
writel(0x, intc->base + (i * CHIP_SIZE) +
--
2.21.0.593.g511ec345e18
[PATCH 4/4] irqchip: ingenic: Alloc generic chips from IRQ domain
By creating the generic chips from the IRQ domain, we don't rely on the
JZ4740_IRQ_BASE macro. It also makes the code a bit cleaner.
Signed-off-by: Paul Cercueil
---
drivers/irqchip/irq-ingenic.c | 30 +-
1 file changed, 17 insertions(+), 13 deletions(-)
diff --git a/drivers/irqchip/irq-ingenic.c b/drivers/irqchip/irq-ingenic.c
index 82a079fa3a3d..06ab3ad22ad2 100644
--- a/drivers/irqchip/irq-ingenic.c
+++ b/drivers/irqchip/irq-ingenic.c
@@ -36,12 +36,14 @@ static irqreturn_t intc_cascade(int irq, void *data)
{
struct ingenic_intc_data *intc = irq_get_handler_data(irq);
struct irq_domain *domain = intc->domain;
+ struct irq_chip_generic *gc;
uint32_t irq_reg;
unsigned i;
for (i = 0; i < intc->num_chips; i++) {
- irq_reg = readl(intc->base + (i * CHIP_SIZE) +
- JZ_REG_INTC_PENDING);
+ gc = irq_get_domain_generic_chip(domain, i * 32);
+
+ irq_reg = irq_reg_readl(gc, JZ_REG_INTC_PENDING);
if (!irq_reg)
continue;
@@ -92,7 +94,7 @@ static int __init ingenic_intc_of_init(struct device_node
*node,
domain = irq_domain_add_legacy(node, num_chips * 32,
JZ4740_IRQ_BASE, 0,
- _domain_simple_ops, NULL);
+ _generic_chip_ops, NULL);
if (!domain) {
err = -ENOMEM;
goto out_unmap_base;
@@ -100,17 +102,17 @@ static int __init ingenic_intc_of_init(struct device_node
*node,
intc->domain = domain;
- for (i = 0; i < num_chips; i++) {
- /* Mask all irqs */
- writel(0x, intc->base + (i * CHIP_SIZE) +
- JZ_REG_INTC_SET_MASK);
+ err = irq_alloc_domain_generic_chips(domain, 32, 1, "INTC",
+handle_level_irq, 0,
+IRQ_NOPROBE | IRQ_LEVEL, 0);
+ if (err)
+ goto out_domain_remove;
- gc = irq_alloc_generic_chip("INTC", 1,
- JZ4740_IRQ_BASE + (i * 32),
- intc->base + (i * CHIP_SIZE),
- handle_level_irq);
+ for (i = 0; i < num_chips; i++) {
+ gc = irq_get_domain_generic_chip(domain, i * 32);
gc->wake_enabled = IRQ_MSK(32);
+ gc->reg_base = intc->base + (i * CHIP_SIZE);
ct = gc->chip_types;
ct->regs.enable = JZ_REG_INTC_CLEAR_MASK;
@@ -121,13 +123,15 @@ static int __init ingenic_intc_of_init(struct device_node
*node,
ct->chip.irq_set_wake = irq_gc_set_wake;
ct->chip.flags = IRQCHIP_MASK_ON_SUSPEND;
- irq_setup_generic_chip(gc, IRQ_MSK(32), 0, 0,
- IRQ_NOPROBE | IRQ_LEVEL);
+ /* Mask all irqs */
+ irq_reg_writel(gc, IRQ_MSK(32), JZ_REG_INTC_SET_MASK);
}
setup_irq(parent_irq, _cascade_action);
return 0;
+out_domain_remove:
+ irq_domain_remove(domain);
out_unmap_base:
iounmap(intc->base);
out_unmap_irq:
--
2.21.0.593.g511ec345e18
[PATCH 1/4] irqchip: ingenic: Drop redundant irq_suspend / irq_resume functions
The same behaviour can be obtained by using the IRQCHIP_MASK_ON_SUSPEND
flag on the IRQ chip.
Signed-off-by: Paul Cercueil
---
drivers/irqchip/irq-ingenic.c | 24 +---
include/linux/irqchip/ingenic.h | 14 --
2 files changed, 1 insertion(+), 37 deletions(-)
delete mode 100644 include/linux/irqchip/ingenic.h
diff --git a/drivers/irqchip/irq-ingenic.c b/drivers/irqchip/irq-ingenic.c
index f126255b3260..06fa810e89bb 100644
--- a/drivers/irqchip/irq-ingenic.c
+++ b/drivers/irqchip/irq-ingenic.c
@@ -10,7 +10,6 @@
#include
#include
#include
-#include
#include
#include
#include
@@ -50,26 +49,6 @@ static irqreturn_t intc_cascade(int irq, void *data)
return IRQ_HANDLED;
}
-static void intc_irq_set_mask(struct irq_chip_generic *gc, uint32_t mask)
-{
- struct irq_chip_regs *regs = >chip_types->regs;
-
- writel(mask, gc->reg_base + regs->enable);
- writel(~mask, gc->reg_base + regs->disable);
-}
-
-void ingenic_intc_irq_suspend(struct irq_data *data)
-{
- struct irq_chip_generic *gc = irq_data_get_irq_chip_data(data);
- intc_irq_set_mask(gc, gc->wake_active);
-}
-
-void ingenic_intc_irq_resume(struct irq_data *data)
-{
- struct irq_chip_generic *gc = irq_data_get_irq_chip_data(data);
- intc_irq_set_mask(gc, gc->mask_cache);
-}
-
static struct irqaction intc_cascade_action = {
.handler = intc_cascade,
.name = "SoC intc cascade interrupt",
@@ -127,8 +106,7 @@ static int __init ingenic_intc_of_init(struct device_node
*node,
ct->chip.irq_mask = irq_gc_mask_disable_reg;
ct->chip.irq_mask_ack = irq_gc_mask_disable_reg;
ct->chip.irq_set_wake = irq_gc_set_wake;
- ct->chip.irq_suspend = ingenic_intc_irq_suspend;
- ct->chip.irq_resume = ingenic_intc_irq_resume;
+ ct->chip.flags = IRQCHIP_MASK_ON_SUSPEND;
irq_setup_generic_chip(gc, IRQ_MSK(32), 0, 0,
IRQ_NOPROBE | IRQ_LEVEL);
diff --git a/include/linux/irqchip/ingenic.h b/include/linux/irqchip/ingenic.h
deleted file mode 100644
index 146558853ad4..
--- a/include/linux/irqchip/ingenic.h
+++ /dev/null
@@ -1,14 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0-or-later */
-/*
- * Copyright (C) 2010, Lars-Peter Clausen
- */
-
-#ifndef __LINUX_IRQCHIP_INGENIC_H__
-#define __LINUX_IRQCHIP_INGENIC_H__
-
-#include
-
-extern void ingenic_intc_irq_suspend(struct irq_data *data);
-extern void ingenic_intc_irq_resume(struct irq_data *data);
-
-#endif
--
2.21.0.593.g511ec345e18
Re: [RFC PATCH] modpost: check for static EXPORT_SYMBOL* functions
Hi. Could you drop the solved ones from the list? Yes, of course. Do you want me to remove all symbols fixed with patches or only those are in-tree now? Should it be like this: 1. "torture_onoff_cleanup" [kernel/torture] "torture_shuffle_cleanup" [kernel/torture] Patch: https://lkml.org/lkml/2019/7/4/411 (accepted) 2. "LZ4HC_setExternalDict" [lib/lz4/lz4hc_compress] Patch: https://lkml.org/lkml/2019/7/8/842 3. "drm_client_close" [drivers/gpu/drm/drm] Patch: https://lkml.org/lkml/2019/7/3/758 (accepted) 4. "ahci_em_messages" [drivers/ata/libahci] Patch: https://lkml.org/lkml/2019/7/10/550 (reviewed) 5. "ftrace_set_clr_event" [vmlinux] Patch: https://lkml.org/lkml/2019/7/4/609 (reviewed) 6. "rmi_2d_sensor_set_input_params" [drivers/input/rmi4/rmi_core] Patch: https://lkml.org/lkml/2019/7/8/999 (accepted) 10. "empty_zero_page" [vmlinux] 11. "phys_base" [vmlinux] 12. "hypercall_page" [vmlinux] Or like this: 1. "empty_zero_page" [vmlinux] 2. "phys_base" [vmlinux] 3. "hypercall_page" [vmlinux] Well, I could remove this list at all. It seems like the following list with existing commits is enough to show the problem of static exported functions. I will resend the patch shortly after. Regards, Denis
Re: [PATCH 3/3][V4] dt-bindings: iio: imu: add bindings for ADIS16460
On Tue, 23 Jul 2019 10:36:40 +0300
Alexandru Ardelean wrote:
> This change adds device-tree bindings for the ADIS16460.
>
> Reviewed-by: Rob Herring
> Signed-off-by: Alexandru Ardelean
Really trivial, but convention (as driven by what git am -s does if nothing
else, is to add extra tags in chronological order. So Rob would be after
you. I tweaked it which I don't always remember to do.
It's not consistent across the kernel but I'll fight for my little corner
to be :)
Applied.
Thanks,
Jonathan
> ---
> .../bindings/iio/imu/adi,adis16460.yaml | 53 +++
> MAINTAINERS | 1 +
> 2 files changed, 54 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/iio/imu/adi,adis16460.yaml
>
> diff --git a/Documentation/devicetree/bindings/iio/imu/adi,adis16460.yaml
> b/Documentation/devicetree/bindings/iio/imu/adi,adis16460.yaml
> new file mode 100644
> index ..0c53009ba7d6
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/imu/adi,adis16460.yaml
> @@ -0,0 +1,53 @@
> +# SPDX-License-Identifier: GPL-2.0
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/iio/imu/adi,adis16460.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Analog Devices ADIS16460 and similar IMUs
> +
> +maintainers:
> + - Dragos Bogdan
> +
> +description: |
> + Analog Devices ADIS16460 and similar IMUs
> +
> https://www.analog.com/media/en/technical-documentation/data-sheets/ADIS16460.pdf
> +
> +properties:
> + compatible:
> +enum:
> + - adi,adis16460
> +
> + reg:
> +maxItems: 1
> +
> + spi-cpha: true
> +
> + spi-cpol: true
> +
> + interrupts:
> +maxItems: 1
> +
> +required:
> + - compatible
> + - reg
> + - interrupts
> +
> +examples:
> + - |
> +#include
> +#include
> +spi0 {
> +#address-cells = <1>;
> +#size-cells = <0>;
> +
> +imu@0 {
> +compatible = "adi,adis16460";
> +reg = <0>;
> +spi-max-frequency = <500>;
> +spi-cpol;
> +spi-cpha;
> +interrupt-parent = <>;
> +interrupts = <0 IRQ_TYPE_LEVEL_HIGH>;
> +};
> +};
> diff --git a/MAINTAINERS b/MAINTAINERS
> index f7de89e82e35..07105e43ea1e 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -951,6 +951,7 @@ S:Supported
> L: linux-...@vger.kernel.org
> W: http://ez.analog.com/community/linux-device-drivers
> F: drivers/iio/imu/adis16460.c
> +F: Documentation/devicetree/bindings/iio/imu/adi,adis16460.yaml
>
> ANALOG DEVICES INC ADP5061 DRIVER
> M: Stefan Popa
Re: [PATCH 2/3][V4] iio: imu: Add support for the ADIS16460 IMU
On Tue, 23 Jul 2019 10:36:39 +0300 Alexandru Ardelean wrote: > The ADIS16460 device is a complete inertial system that includes a triaxial > gyroscope and a triaxial accelerometer. It's more simplified design than > that of the ADIS16480, and does not offer the triaxial magnetometers & > pressure sensors. It does also have a temperature sensor (like the > ADIS16480). > Since it is part of the ADIS16XXX family, it re-uses parts of the ADIS > library. > > Naturally, the register map is different and much more simplified than the > ADIS16480 subfamily, so it cannot be integrated into that driver. A major > difference is that the registers are not paged. > > One thing that is particularly special about it, is that it requires a > higher delay between CS changes (i.e. when CS goes up, the spec recommends > that it be brought down after a minimum of 16 uS). > Other ADIS chips require (via spec) a minimum of 2 uS between CS changes. > The kernel's 10 uS default should be fine for those other chips; they > haven't been tested with lower CS change delays yet. > > Datasheet: > > https://www.analog.com/media/en/technical-documentation/data-sheets/adis16460.pdf > > Signed-off-by: Dragos Bogdan > Signed-off-by: Michael Hennerich > Signed-off-by: Alexandru Ardelean Applied to the togreg branch of iio.git and pushed out as testing. Note there was a typo / variable naming inconsistency that I fixed up. See inline. Thanks, Jonathan > --- > MAINTAINERS | 7 + > drivers/iio/imu/Kconfig | 12 + > drivers/iio/imu/Makefile| 1 + > drivers/iio/imu/adis16460.c | 489 > 4 files changed, 509 insertions(+) > create mode 100644 drivers/iio/imu/adis16460.c > > diff --git a/MAINTAINERS b/MAINTAINERS > index 783569e3c4b4..f7de89e82e35 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -945,6 +945,13 @@ L: linux-...@vger.kernel.org > F: include/linux/iio/imu/adis.h > F: drivers/iio/imu/adis.c > > +ANALOG DEVICES INC ADIS16460 DRIVER > +M: Dragos Bogdan > +S: Supported > +L: linux-...@vger.kernel.org > +W: http://ez.analog.com/community/linux-device-drivers > +F: drivers/iio/imu/adis16460.c > + > ANALOG DEVICES INC ADP5061 DRIVER > M: Stefan Popa > L: linux...@vger.kernel.org > diff --git a/drivers/iio/imu/Kconfig b/drivers/iio/imu/Kconfig > index 4957e6df447e..f3c7282321a8 100644 > --- a/drivers/iio/imu/Kconfig > +++ b/drivers/iio/imu/Kconfig > @@ -17,6 +17,18 @@ config ADIS16400 > adis16365, adis16400 and adis16405 triaxial inertial sensors > (adis16400 series also have magnetometers). > > +config ADIS16460 > + tristate "Analog Devices ADIS16460 and similar IMU driver" > + depends on SPI > + select IIO_ADIS_LIB > + select IIO_ADIS_LIB_BUFFER if IIO_BUFFER > + help > + Say yes here to build support for Analog Devices ADIS16460 inertial > + sensor. > + > + To compile this driver as a module, choose M here: the module will be > + called adis16460. > + > config ADIS16480 > tristate "Analog Devices ADIS16480 and similar IMU driver" > depends on SPI > diff --git a/drivers/iio/imu/Makefile b/drivers/iio/imu/Makefile > index 9e452fce1aaf..4a6958865504 100644 > --- a/drivers/iio/imu/Makefile > +++ b/drivers/iio/imu/Makefile > @@ -5,6 +5,7 @@ > > # When adding new entries keep the list in alphabetical order > obj-$(CONFIG_ADIS16400) += adis16400.o > +obj-$(CONFIG_ADIS16460) += adis16460.o > obj-$(CONFIG_ADIS16480) += adis16480.o > > adis_lib-y += adis.o > diff --git a/drivers/iio/imu/adis16460.c b/drivers/iio/imu/adis16460.c > new file mode 100644 > index ..db713cba75a2 > --- /dev/null > +++ b/drivers/iio/imu/adis16460.c > @@ -0,0 +1,489 @@ > +// SPDX-License-Identifier: GPL-2.0+ > +/* > + * ADIS16460 IMU driver > + * > + * Copyright 2019 Analog Devices Inc. > + */ > + > +#include > +#include > +#include > + > +#include > +#include > + > +#include > + > +#define ADIS16460_REG_FLASH_CNT 0x00 > +#define ADIS16460_REG_DIAG_STAT 0x02 > +#define ADIS16460_REG_X_GYRO_LOW 0x04 > +#define ADIS16460_REG_X_GYRO_OUT 0x06 > +#define ADIS16460_REG_Y_GYRO_LOW 0x08 > +#define ADIS16460_REG_Y_GYRO_OUT 0x0A > +#define ADIS16460_REG_Z_GYRO_LOW 0x0C > +#define ADIS16460_REG_Z_GYRO_OUT 0x0E > +#define ADIS16460_REG_X_ACCL_LOW 0x10 > +#define ADIS16460_REG_X_ACCL_OUT 0x12 > +#define ADIS16460_REG_Y_ACCL_LOW 0x14 > +#define ADIS16460_REG_Y_ACCL_OUT 0x16 > +#define ADIS16460_REG_Z_ACCL_LOW 0x18 > +#define ADIS16460_REG_Z_ACCL_OUT 0x1A > +#define ADIS16460_REG_SMPL_CNTR 0x1C > +#define ADIS16460_REG_TEMP_OUT 0x1E > +#define ADIS16460_REG_X_DELT_ANG 0x24 > +#define ADIS16460_REG_Y_DELT_ANG 0x26 > +#define ADIS16460_REG_Z_DELT_ANG 0x28 > +#define ADIS16460_REG_X_DELT_VEL 0x2A > +#define ADIS16460_REG_Y_DELT_VEL 0x2C > +#define
Re: [PATCH 1/3][V4] iio: imu: adis: Add support for SPI transfer cs_change_delay
On Tue, 23 Jul 2019 10:36:38 +0300
Alexandru Ardelean wrote:
> The ADIS16460 requires a higher delay before the next transfer. Since the
> SPI framework supports configuring the delay before the next transfer, this
> driver will become the first user of it.
>
> The support for this functionality in ADIS16460 requires an addition to the
> ADIS lib to support the `cs_change_delay` functionality from the SPI
> subsystem.
>
> Signed-off-by: Michael Hennerich
> Signed-off-by: Alexandru Ardelean
Applied to the togreg branch of iio.git and pushed out as testing for
the autobuilders to play with it.
Thanks,
Jonathan
> ---
> drivers/iio/imu/adis.c | 12
> include/linux/iio/imu/adis.h | 2 ++
> 2 files changed, 14 insertions(+)
>
> diff --git a/drivers/iio/imu/adis.c b/drivers/iio/imu/adis.c
> index 30281e91dbf9..1631c255deab 100644
> --- a/drivers/iio/imu/adis.c
> +++ b/drivers/iio/imu/adis.c
> @@ -39,18 +39,24 @@ int adis_write_reg(struct adis *adis, unsigned int reg,
> .len = 2,
> .cs_change = 1,
> .delay_usecs = adis->data->write_delay,
> + .cs_change_delay = adis->data->cs_change_delay,
> + .cs_change_delay_unit = SPI_DELAY_UNIT_USECS,
> }, {
> .tx_buf = adis->tx + 2,
> .bits_per_word = 8,
> .len = 2,
> .cs_change = 1,
> .delay_usecs = adis->data->write_delay,
> + .cs_change_delay = adis->data->cs_change_delay,
> + .cs_change_delay_unit = SPI_DELAY_UNIT_USECS,
> }, {
> .tx_buf = adis->tx + 4,
> .bits_per_word = 8,
> .len = 2,
> .cs_change = 1,
> .delay_usecs = adis->data->write_delay,
> + .cs_change_delay = adis->data->cs_change_delay,
> + .cs_change_delay_unit = SPI_DELAY_UNIT_USECS,
> }, {
> .tx_buf = adis->tx + 6,
> .bits_per_word = 8,
> @@ -133,12 +139,16 @@ int adis_read_reg(struct adis *adis, unsigned int reg,
> .len = 2,
> .cs_change = 1,
> .delay_usecs = adis->data->write_delay,
> + .cs_change_delay = adis->data->cs_change_delay,
> + .cs_change_delay_unit = SPI_DELAY_UNIT_USECS,
> }, {
> .tx_buf = adis->tx + 2,
> .bits_per_word = 8,
> .len = 2,
> .cs_change = 1,
> .delay_usecs = adis->data->read_delay,
> + .cs_change_delay = adis->data->cs_change_delay,
> + .cs_change_delay_unit = SPI_DELAY_UNIT_USECS,
> }, {
> .tx_buf = adis->tx + 4,
> .rx_buf = adis->rx,
> @@ -146,6 +156,8 @@ int adis_read_reg(struct adis *adis, unsigned int reg,
> .len = 2,
> .cs_change = 1,
> .delay_usecs = adis->data->read_delay,
> + .cs_change_delay = adis->data->cs_change_delay,
> + .cs_change_delay_unit = SPI_DELAY_UNIT_USECS,
> }, {
> .rx_buf = adis->rx + 2,
> .bits_per_word = 8,
> diff --git a/include/linux/iio/imu/adis.h b/include/linux/iio/imu/adis.h
> index 3428d06b2f44..4c53815bb729 100644
> --- a/include/linux/iio/imu/adis.h
> +++ b/include/linux/iio/imu/adis.h
> @@ -26,6 +26,7 @@ struct adis_burst;
> * struct adis_data - ADIS chip variant specific data
> * @read_delay: SPI delay for read operations in us
> * @write_delay: SPI delay for write operations in us
> + * @cs_change_delay: SPI delay between CS changes in us
> * @glob_cmd_reg: Register address of the GLOB_CMD register
> * @msc_ctrl_reg: Register address of the MSC_CTRL register
> * @diag_stat_reg: Register address of the DIAG_STAT register
> @@ -35,6 +36,7 @@ struct adis_burst;
> struct adis_data {
> unsigned int read_delay;
> unsigned int write_delay;
> + unsigned int cs_change_delay;
>
> unsigned int glob_cmd_reg;
> unsigned int msc_ctrl_reg;
Re: [PATCH 2/2] devcoredump: fix typo in comment
On Sun, 2019-07-28 at 00:59 +0900, Akinobu Mita wrote: > s/dev_coredumpmsg/dev_coredumpsg/ Oops, thanks Reviewed-by: Johannes Berg Greg, I think before you took these patches? Thanks, johannes
Re: [5.2 REGRESSION] Generic vDSO breaks seccomp-enabled userspace on i386
On Sat, 27 Jul 2019, Andy Lutomirski wrote: > On Fri, Jul 26, 2019 at 11:01 AM Sean Christopherson > wrote: > > > > +cc Paul > > > > On Wed, Jul 24, 2019 at 01:56:34AM +0200, Thomas Gleixner wrote: > > > On Tue, 23 Jul 2019, Kees Cook wrote: > > > > > > > On Wed, Jul 24, 2019 at 12:59:03AM +0200, Thomas Gleixner wrote: > > > > > And as we have sys_clock_gettime64() exposed for 32bit anyway you > > > > > need to > > > > > deal with that in seccomp independently of the VDSO. It does not make > > > > > sense > > > > > to treat sys_clock_gettime() differently than sys_clock_gettime64(). > > > > > They > > > > > both expose the same information, but the latter is y2038 safe. > > > > > > > > Okay, so combining Andy's ideas on aliasing and "more seccomp flags", > > > > we could declare that clock_gettime64() is not filterable on 32-bit at > > > > all without the magic SECCOMP_IGNORE_ALIASES flag or something. Then we > > > > would alias clock_gettime64 to clock_gettime _before_ the first > > > > evaluation > > > > (unless SECCOMP_IGNORE_ALIASES is set)? > > > > > > > > (When was clock_gettime64() introduced? Is it too long ago to do this > > > > "you can't filter it without a special flag" change?) > > > > > > clock_gettime64() and the other sys_*time64() syscalls which address the > > > y2038 issue were added in 5.1 > > > > Paul Bolle pointed out that this regression showed up in v5.3-rc1, not > > v5.2. In Paul's case, systemd-journal is failing. > > I think it's getting quite late to start inventing new seccomp > features to fix this. I think the right solution for 5.3 is to change > the 32-bit vdso fallback to use the old clock_gettime, i.e. > clock_gettime32. This is obviously not an acceptable long-term > solution. Sigh. I'll have a look Thanks, tglx
Re: [GIT PULL] Wimplicit-fallthrough patches for 5.3-rc2
The pull request you sent on Thu, 25 Jul 2019 21:55:21 -0500: > git://git.kernel.org/pub/scm/linux/kernel/git/gustavoars/linux.git > tags/Wimplicit-fallthrough-5.3-rc2 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/88c5083442454e5e8a505b11fa16f32d2879651e Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [PATCH 2/5] MIPS: lantiq: use a generic "EBU" driver for Falcon and XWAY SoCs
Hi John, On Sat, Jul 27, 2019 at 8:35 PM John Crispin wrote: > > > On 27/07/2019 19:53, Martin Blumenstingl wrote: > > + * Copyright (C) 2011-2012 John Crispin > > could you change that to j...@phrozen.org please sure, I'll update it when I have to re-send this series Martin
Re: [PATCH 2/5] MIPS: lantiq: use a generic "EBU" driver for Falcon and XWAY SoCs
On 27/07/2019 19:53, Martin Blumenstingl wrote: + * Copyright (C) 2011-2012 John Crispin could you change that to j...@phrozen.org please John
Re: [PATCH v2 5/8] clk: meson: meson8b: migrate to the new parent description method
Hi Alexandre, On Thu, Jul 25, 2019 at 6:47 PM Alexandre Mergnat wrote: > > This clock controller use the string comparison method to describe parent > relation between the clocks, which is not optimized. > > Migrate to the new way by using .parent_hws where possible (ie. when > all clocks are local to the controller) and use .parent_data otherwise. > > Signed-off-by: Alexandre Mergnat thank you for working on this - everything looks fine to me, so feel free to add: Reviewed-by: Martin Blumenstingl and on my Odroid-C1+: Tested-by: Martin Blumenstingl (I compared the output of /sys/kernel/debug/clk/clk_summary before and after this patch and it's identical. CPU frequency scaling also still works) Martin
[PATCH 2/2] lightnvm: print error when target is not found
If userspace requests target to be removed, nvm_remove_tgt() will
iterate the nvm_devices to find out the given target, but if not
found, then it should print out the error.
Cc: Matias Bjørling
Cc: Javier González
Signed-off-by: Minwoo Im
---
drivers/lightnvm/core.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/lightnvm/core.c b/drivers/lightnvm/core.c
index 4c7b48f72e80..4c89a2420a51 100644
--- a/drivers/lightnvm/core.c
+++ b/drivers/lightnvm/core.c
@@ -494,8 +494,11 @@ static int nvm_remove_tgt(struct nvm_ioctl_remove *remove)
}
up_read(_lock);
- if (!t)
+ if (!t) {
+ pr_err("failed to remove target %s not found\n",
+ remove->tgtname);
return 1;
+ }
__nvm_remove_target(t, true);
kref_put(>ref, nvm_free);
--
2.17.1
Re: [PATCH 5/6] clk: imx8mq: Remove CLK_IS_CRITICAL flag for IMX8MQ_CLK_TMU_ROOT
Hi Daniel, On Sat, Jul 27, 2019 at 01:26:50AM +0300, Daniel Baluta wrote: > Hi all, > > latest linux-next hangs at boot. > > commit fde50b96be821ac9673a7e00847cc4605bd88f34 (HEAD -> master, tag: > next-20190726, origin/master, origin/HEAD) > Author: Stephen Rothwell > Date: Fri Jul 26 15:18:02 2019 +1000 > > Add linux-next specific files for 20190726 > > Signed-off-by: Stephen Rothwell > > > I know this is crazy but reverting commit: > > commit 431bdd1df48ee2896ea9980d9153e3aeaf0c81ef (refs/bisect/bad) > Author: Anson Huang > Date: Fri Jul 5 12:56:11 2019 +0800 > > clk: imx8mq: Remove CLK_IS_CRITICAL flag for IMX8MQ_CLK_TMU_ROOT > > IMX8MQ_CLK_TMU_ROOT is ONLY used for thermal module, the driver > should manage this clock, so no need to have CLK_IS_CRITICAL flag > set. > > > > makes the boot work again. I noticed a boot hang yesterday on next-20190726 when loading the qoriq_thermal which I worked around by blacklisting it. The fsl,imx8mq-tmu node specifies a clock (IMX8MQ_CLK_TMU_ROOT) but does not seem to enable, shouldn't it do so? Cheers, -- Guido
Re: [PATCH v2] counter/ftm-quaddec: Use device-managed registration API
On Sat, Jul 27, 2019 at 02:31:33PM +0100, Jonathan Cameron wrote:
> On Fri, 26 Jul 2019 14:51:30 +0200
> Patrick Havelange wrote:
>
> > Hello,
> >
> > On Fri, Jul 26, 2019 at 4:28 AM Chuhong Yuan wrote:
> > >
> > > Make use of devm_counter_register.
> > > Then we can remove redundant unregistration API
> > > usage to make code simpler.
> > >
> > > Signed-off-by: Chuhong Yuan
> > > ---
> > > Changes in v2:
> > > - Use devm_add_action_or_reset to keep
> > > resource release order.
> >
> > This is better now indeed.
> >
> > However it seems there is an issue with the mail/patch format, I'm
> > unable to apply it with git am, and if you look at
> > https://lore.kernel.org/patchwork/patch/1105782/ the diff section is
> > missing the beginning of the patch. I don't know why, but I think it
> > should be looked into.
> >
> > Otherwise, it's fine by me.
> Hi Patrick,
>
> A formal, Acked-by or Reviewed-by definitely preferred if you are happy
> to give one.
>
> This looks fine to me as well. William, if you are happy with the resend
> of this, then let me know if you want me to queue it up.
>
> Thanks,
>
> Jonathan
I'm all right with these changes too. Feel free to queue up the resend
version in your tree when you are ready.
William Breathitt Gray
>
> >
> > Regards,
> >
> > Patrick Havelange
> >
> >
> > > - _remove() function is redundant now,
> > > delete it.
> > >
> > > drivers/counter/ftm-quaddec.c | 31 +++
> > > 1 file changed, 11 insertions(+), 20 deletions(-)
> > >
> > > diff --git a/drivers/counter/ftm-quaddec.c b/drivers/counter/ftm-quaddec.c
> > > index 68a9b7393457..76c70a6c3593 100644
> > > --- a/drivers/counter/ftm-quaddec.c
> > > +++ b/drivers/counter/ftm-quaddec.c
> > > @@ -100,16 +100,17 @@ static void ftm_quaddec_init(struct ftm_quaddec
> > > *ftm)
> > > ftm_set_write_protection(ftm);
> > > }
> > >
> > > -static void ftm_quaddec_disable(struct ftm_quaddec *ftm)
> > > +static void ftm_quaddec_disable(void *ftm)
> > > {
> > > - ftm_clear_write_protection(ftm);
> > > - ftm_write(ftm, FTM_MODE, 0);
> > > - ftm_write(ftm, FTM_QDCTRL, 0);
> > > + struct ftm_quaddec *ftm_qua = ftm;
> > >
> > > + ftm_clear_write_protection(ftm_qua);
> > > + ftm_write(ftm_qua, FTM_MODE, 0);
> > > + ftm_write(ftm_qua, FTM_QDCTRL, 0);
> > > /*
> > > * This is enough to disable the counter. No clock has been
> > > * selected by writing to FTM_SC in init()
> > > */
> > > - ftm_set_write_protection(ftm);
> > > + ftm_set_write_protection(ftm_qua);
> > > }
> > >
> > > static int ftm_quaddec_get_prescaler(struct counter_device *counter,
> > > @@ -316,22 +317,13 @@ static int ftm_quaddec_probe(struct platform_device
> > > *pdev)
> > > mutex_init(>ftm_quaddec_mutex);
> > >
> > > ftm_quaddec_init(ftm);
> > > -
> > > - ret = counter_register(>counter);
> > > + ret = devm_add_action_or_reset(>dev, ftm_quaddec_disable,
> > > ftm);
> > > if (ret)
> > > - ftm_quaddec_disable(ftm);
> > > -
> > > - return ret;
> > > -}
> > > -
> > > -static int ftm_quaddec_remove(struct platform_device *pdev)
> > > -{
> > > - struct ftm_quaddec *ftm = platform_get_drvdata(pdev);
> > > -
> > > - counter_unregister(>counter);
> > > -
> > > - ftm_quaddec_disable(ftm);
> > > + return ret;
> > >
> > > + ret = devm_counter_register(>dev, >counter);
> > > + if (ret)
> > > + return ret;
> > > return 0;
> > > }
> > >
> > > @@ -346,7 +338,6 @@ static struct platform_driver ftm_quaddec_driver = {
> > > .of_match_table = ftm_quaddec_match,
> > > },
> > > .probe = ftm_quaddec_probe,
> > > - .remove = ftm_quaddec_remove,
> > > };
> > >
> > > module_platform_driver(ftm_quaddec_driver);
> > > --
> > > 2.20.1
> > >
>
