Re: [linux-sunxi] [PATCH v3 4/5] ARM: dts: sun8i: h3: enable USB OTG on Orange Pi One
On Tue, Mar 7, 2017 at 6:34 AM, Icenowy Zheng wrote: > Orange Pi One features a MicroUSB port that can work in both host mode > and peripheral mode. > > When in host mode, its VBUS is controlled via a GPIO; when in peripheral > mode, its VBUS cannot be used to power up the board. > > Add support for this port. > > Signed-off-by: Icenowy Zheng Acked-by: Chen-Yu Tsai
[PATCH] net: mvneta: support suspend and resume
Add basic support for handling suspend and resume.
Signed-off-by: Jane Li
---
drivers/net/ethernet/marvell/mvneta.c | 44 +++
1 file changed, 44 insertions(+)
diff --git a/drivers/net/ethernet/marvell/mvneta.c
b/drivers/net/ethernet/marvell/mvneta.c
index 61dd446..4f16342 100644
--- a/drivers/net/ethernet/marvell/mvneta.c
+++ b/drivers/net/ethernet/marvell/mvneta.c
@@ -4405,6 +4405,49 @@ static int mvneta_remove(struct platform_device *pdev)
return 0;
}
+#ifdef CONFIG_PM_SLEEP
+static int mvneta_suspend(struct device *device)
+{
+ struct net_device *dev = dev_get_drvdata(device);
+ struct mvneta_port *pp = netdev_priv(dev);
+
+ if (netif_running(dev))
+ mvneta_stop(dev);
+ netif_device_detach(dev);
+ clk_disable_unprepare(pp->clk_bus);
+ clk_disable_unprepare(pp->clk);
+ return 0;
+}
+
+static int mvneta_resume(struct device *device)
+{
+ struct net_device *dev = dev_get_drvdata(device);
+ struct mvneta_port *pp = netdev_priv(dev);
+ int err;
+
+ clk_prepare_enable(pp->clk);
+ clk_prepare_enable(pp->clk_bus);
+ mvneta_defaults_set(pp);
+ err = mvneta_port_power_up(pp, pp->phy_interface);
+ if (err < 0) {
+ dev_err(device, "can't power up port\n");
+ return err;
+ }
+
+ if (pp->use_inband_status)
+ mvneta_fixed_link_update(pp, dev->phydev);
+
+ netif_device_attach(dev);
+ if (netif_running(dev))
+ mvneta_open(dev);
+ return 0;
+}
+#endif
+
+static const struct dev_pm_ops mvneta_pm_ops = {
+ SET_LATE_SYSTEM_SLEEP_PM_OPS(mvneta_suspend, mvneta_resume)
+};
+
static const struct of_device_id mvneta_match[] = {
{ .compatible = "marvell,armada-370-neta" },
{ .compatible = "marvell,armada-xp-neta" },
@@ -4419,6 +4462,7 @@ static int mvneta_remove(struct platform_device *pdev)
.driver = {
.name = MVNETA_DRIVER_NAME,
.of_match_table = mvneta_match,
+ .pm = &mvneta_pm_ops,
},
};
--
1.9.1
Re: stable build: 203 builds: 4 failed, 199 passed, 5 errors, 41 warnings (v4.10.1)
On Tue, Feb 28, 2017 at 02:31:51PM +0100, Arnd Bergmann wrote:
> On Sun, Feb 26, 2017 at 2:47 PM, kernelci.org bot wrote:
> > stable build: 203 builds: 4 failed, 199 passed, 5 errors, 41 warnings
>
> A lot of fixes for these build problems have now landed in mainline, and
> we could backport them as soon as they are considered stable enough.
> If all of these make it into stable, we should have a clean build on MIPS and
> ARM, and only the KASAN warnings remaining x86 and arm64.
>
> > capcella_defconfig (mips) — PASS, 0 errors, 1 warning, 0 section mismatches
> >
> > Warnings:
> > crypto/wp512.c:987:1: warning: the frame size of 1112 bytes is larger than
> > 1024 bytes [-Wframe-larger-than=]
>
> 7d6e91050267 ("crypto: improve gcc optimization flags for serpent and wp512")
>
> > defconfig+CONFIG_KASAN=y (x86) — PASS, 0 errors, 5 warnings, 0 section
> > mismatches
> >
> > Warnings:
> > drivers/tty/vt/keyboard.c:1470:1: warning: the frame size of 2344 bytes is
> > larger than 2048 bytes [-Wframe-larger-than=]
> > net/wireless/nl80211.c:1410:1: warning: the frame size of 2232 bytes is
> > larger than 2048 bytes [-Wframe-larger-than=]
> > net/wireless/nl80211.c:4389:1: warning: the frame size of 2232 bytes is
> > larger than 2048 bytes [-Wframe-larger-than=]
> > net/wireless/nl80211.c:5689:1: warning: the frame size of 2064 bytes is
> > larger than 2048 bytes [-Wframe-larger-than=]
> > net/wireless/nl80211.c:1895:1: warning: the frame size of 3720 bytes is
> > larger than 2048 bytes [-Wframe-larger-than=]
>
> I'm still working on the fix, the same thing happens in mainline.
>
> > Warnings:
> > arch/mips/configs/ip22_defconfig:70:warning: symbol value 'm' invalid for
> > NF_CT_PROTO_DCCP
> > arch/mips/configs/ip22_defconfig:71:warning: symbol value 'm' invalid for
> > NF_CT_PROTO_UDPLITE
>
> 9ddc16ad8e0b ("MIPS: Update defconfigs for NF_CT_PROTO_DCCP/UDPLITE change")
>
> > ip27_defconfig (mips) — FAIL, 4 errors, 1 warning, 0 section mismatches
> >
> > Errors:
> > arch/mips/include/asm/mach-generic/spaces.h:28:0: error: "CAC_BASE"
> > redefined [-Werror]
> > arch/mips/include/asm/mach-generic/spaces.h:28:0: error: "CAC_BASE"
> > redefined [-Werror]
>
> 1742ac265046 ("MIPS: VDSO: avoid duplicate CAC_BASE definition")
>
> > drivers/net/ethernet/qlogic/qlge/qlge_main.c:4819:1: error: insn does not
> > satisfy its constraints:
> > drivers/net/ethernet/qlogic/qlge/qlge_main.c:4819:1: internal compiler
> > error: in extract_constrain_insn, at recog.c:2190
> > Warnings:
>
> b61764946839 ("MIPS: ip27: Disable qlge driver in defconfig")
>
> > arch/mips/configs/ip27_defconfig:136:warning: symbol value 'm' invalid for
> > SCSI_DH
>
> ea58fca1842a ("MIPS: Update ip27_defconfig for SCSI_DH change")
>
> > ip28_defconfig (mips) — FAIL, 1 error, 0 warnings, 0 section mismatches
> >
> > Errors:
> > arch/mips/sgi-ip22/Platform:29: *** gcc doesn't support needed option
> > -mr10k-cache-barrier=store. Stop.
>
> 23ca9b522383 ("MIPS: ip22: Fix ip28 build for modern gcc")
>
> > lemote2f_defconfig (mips) — PASS, 0 errors, 2 warnings, 0 section mismatches
> >
> > Warnings:
> > arch/mips/configs/lemote2f_defconfig:42:warning: symbol value 'm' invalid
> > for CPU_FREQ_STAT
>
> b3f6046186ef ("MIPS: Update lemote2f_defconfig for CPU_FREQ_STAT change")
>
> > msp71xx_defconfig (mips) — PASS, 0 errors, 1 warning, 0 section mismatches
> >
> > Warnings:
> > drivers/mtd/maps/pmcmsp-flash.c:149:30: warning: passing argument 1 of
> > 'strncpy' discards 'const' qualifier from pointer target type
> > [-Wdiscarded-qualifiers]
>
> 906b268477bc ("mtd: pmcmsp: use kstrndup instead of kmalloc+strncpy")
>
> > rt305x_defconfig (mips) — PASS, 0 errors, 5 warnings, 0 section mismatches
> >
> > Warnings:
> > arch/mips/ralink/prom.c:70:2: warning: 'argc' is used uninitialized in this
> > function [-Wuninitialized]
> > arch/mips/ralink/prom.c:70:2: warning: 'argv' is used uninitialized in this
> > function [-Wuninitialized]
>
> 9c48568b3692 ("MIPS: ralink: Cosmetic change to prom_init().")
>
> > arch/mips/ralink/timer.c:104:13: warning: 'rt_timer_disable' defined but not
> > used [-Wunused-function]
> > arch/mips/ralink/timer.c:74:13: warning: 'rt_timer_free' defined but not
> > used [-Wunused-function]
>
> d92240d12a9c ("MIPS: ralink: Remove unused timer functions")
>
> > arch/mips/ralink/rt305x.c:92:13: warning: 'rt305x_wdt_reset' defined but not
> > used [-Wunused-function]
>
> 886f9c69fc68 ("MIPS: ralink: Remove unused rt*_wdt_reset functions")
All now queued up in the stable trees, thanks.
greg k-h
Re: [linux-sunxi] [PATCH v3 5/5] ARM: dts: sun8i: h2+: enable USB OTG for Orange Pi Zero board
Hi,
On Tue, Mar 7, 2017 at 6:34 AM, Icenowy Zheng wrote:
> Orange Pi Zero board features a USB OTG port, which has a ID pin, and
> can be used to power up the board. However, even if the board is powered
> via +5V pin in GPIO/expansion headers, the VBUS in the OTG port cannot
> be powered up, thus it's impossible to use it in host mode with simple
> OTG cables.
>
> Add support for it in peripheral mode.
>
> If someone really want to use it in host mode, the mode of PHY can be
> switch via sysfs, then use a powered USB OTG cable or powered USB HUB to
> power up external USB devices.
>
> Signed-off-by: Icenowy Zheng
> ---
> New patch in v3.
>
> arch/arm/boot/dts/sun8i-h2-plus-orangepi-zero.dts | 14 ++
> 1 file changed, 14 insertions(+)
>
> diff --git a/arch/arm/boot/dts/sun8i-h2-plus-orangepi-zero.dts
> b/arch/arm/boot/dts/sun8i-h2-plus-orangepi-zero.dts
> index b7ca916d871d..63f819394b98 100644
> --- a/arch/arm/boot/dts/sun8i-h2-plus-orangepi-zero.dts
> +++ b/arch/arm/boot/dts/sun8i-h2-plus-orangepi-zero.dts
> @@ -96,6 +96,10 @@
> };
> };
>
> +&ehci0 {
> + status = "okay";
> +};
> +
> &ehci1 {
> status = "okay";
> };
> @@ -132,6 +136,10 @@
> bias-pull-up;
> };
>
> +&ohci0 {
> + status = "okay";
> +};
> +
> &ohci1 {
> status = "okay";
> };
> @@ -154,7 +162,13 @@
> status = "disabled";
> };
>
> +&usb_otg {
> + dr_mode = "peripheral";
> + status = "okay";
> +};
> +
> &usbphy {
> /* USB VBUS is always on */
This comment does not match your commit message, which says it's always off.
ChenYu
> status = "okay";
> + usb0_id_det-gpios = <&pio 6 12 GPIO_ACTIVE_HIGH>; /* PG12 */
> };
> --
> 2.11.1
>
> --
> You received this message because you are subscribed to the Google Groups
> "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to linux-sunxi+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
Re: stable build: 199 builds: 1 failed, 198 passed, 1 error, 31 warnings (v4.4.52)
On Tue, Feb 28, 2017 at 02:55:42PM +0100, Arnd Bergmann wrote:
> On Sun, Feb 26, 2017 at 3:09 PM, kernelci.org bot wrote:
> > stable build: 199 builds: 1 failed, 198 passed, 1 error, 31 warnings
>
> A few additional patches are missing here, besides the ones I have
> listed for 4.9 and v4.10
>
> > Warnings:
> > drivers/net/ethernet/ti/cpmac.c:1240:2: warning: #warning FIXME: unhardcode
> > gpio&reset bits [-Wcpp]
>
> d43e6fb4ac4a ("cpmac: remove hopeless #warning")
>
> > ci20_defconfig (mips) — PASS, 0 errors, 1 warning, 0 section mismatches
> >
> > Warnings:
> > mm/memcontrol.c:4153:27: warning: 'mem_cgroup_id_get_online' defined but not
> > used [-Wunused-function]
>
> 358c07fcc3b6 ("mm: memcontrol: avoid unused function warning")
>
> > decstation_defconfig (mips) — PASS, 0 errors, 3 warnings, 0 section
> > mismatches
> >
> > Warnings:
> > arch/mips/dec/int-handler.S:149: Warning: macro instruction expanded into
> > multiple instructions in a branch delay slot
> > arch/mips/dec/int-handler.S:198: Warning: macro instruction expanded into
> > multiple instructions in a branch delay slot
>
> 3021773c7c3e ("MIPS: DEC: Avoid la pseudo-instruction in delay slots")
>
> > nlm_xlp_defconfig (mips) — PASS, 0 errors, 4 warnings, 0 section mismatches
> >
> > Warnings:
> > arch/mips/netlogic/common/reset.S:53:0: warning: "CP0_EBASE" redefined
> > arch/mips/netlogic/common/smpboot.S:51:0: warning: "CP0_EBASE" redefined
>
> 32eb6e8bee14 ("MIPS: Netlogic: Fix CP0_EBASE redefinition warnings")
And I've added these as well, thanks.
greg k-h
hwclock make clock_gettime not accurate
HI guys. I'm doing some tests about clock_gettime. And I found that clock_gettime will be affected by hwclock. It makes clock_gettime slip advance some milliseconds. Actually, each line prints out every 1ms. $ ./a.out -r CLOCK_MONOTONIC 130 ↵ Using delay=1 ms between loop. Using clock=CLOCK_MONOTONIC. Clock resolution sec=0 nsec=1 Initial time sec=1621884 nsec=285113956 [delay=1ms] Slip time: 0 s 32 ms <-hwclock [delay=1ms] Slip time: 0 s 16 ms <-hwclock >From perf: $ perf record -F 999 hwclock # To display the perf.data header info, please use --header/--header-only options. # # Samples: 22 of event 'cpu-clock' # Event count (approx.): 22022022 # # Overhead Command Shared Object Symbol # ... . ... # 77.27% hwclock [kernel.kallsyms] [k] native_read_tsc 13.64% hwclock [kernel.kallsyms] [k] delay_tsc 4.55% hwclock [kernel.kallsyms] [k] _raw_spin_unlock_irqrestore 4.55% hwclock libc-2.17.so [.] __strftime_l $perf record -F 999 ./a.out # To display the perf.data header info, please use --header/--header-only options. # # Samples: 7K of event 'cpu-clock' # Event count (approx.): 79010100220 # # Overhead Command Shared Object Symbol # ... . ... # 28.18% a.out[kernel.kallsyms] [k] _raw_spin_unlock_irqrestore 20.64% a.out[vdso] [.] __vdso_clock_gettime 18.46% a.out[kernel.kallsyms] [k] native_read_tsc 9.81% a.outa.out [.] busy_loop 4.62% a.outa.out [.] calc_1ms 2.15% a.outlibc-2.17.so [.] clock_gettime 2.02% a.outa.out [.] overhead_clock I thought there is a lock contention. However, when I ran two a.out, the output is correct, not like hwclock. Anyone knows why? Thanks.
Re: Fwd: stable build: 111 builds: 2 failed, 109 passed, 1 error, 29 warnings (v4.10.2)
On Mon, Mar 13, 2017 at 04:51:41PM +0100, Arnd Bergmann wrote: > On Sun, Mar 12, 2017 at 10:44 AM, kernelci.org bot wrote: > > Build Failures Detected: > > All but two failures have been fixed, nice! > > > x86: gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4) > > allmodconfig+CONFIG_OF=n FAIL > > Not sure what's going on here, I've seen this failure a few times on kernelci > but cannot reproduce it here: > > /bin/sh: 1: > /home/buildslave/workspace/kernel-builder/arch/x86/defconfig/allmodconfig+CONFIG_OF=n/label/builder/stable/build-x86/tools/objtool//fixdep: > Permission denied > /home/buildslave/workspace/kernel-builder/arch/x86/defconfig/allmodconfig+CONFIG_OF=n/label/builder/stable/tools/build/Makefile.build:91: > recipe for target > '/home/buildslave/workspace/kernel-builder/arch/x86/defconfig/allmodconfig+CONFIG_OF=n/label/builder/stable/build-x86/tools/objtool/pager.o' > failed > make[5]: *** > [/home/buildslave/workspace/kernel-builder/arch/x86/defconfig/allmodconfig+CONFIG_OF=n/label/builder/stable/build-x86/tools/objtool/pager.o] > Error 126 > make[5]: *** Waiting for unfinished jobs > > > Warnings summary: > > 4 crypto/wp512.c:987:1: warning: the frame size of 1112 bytes is larger > > than 1024 bytes [-Wframe-larger-than=] > > 2 crypto/wp512.c:987:1: warning: the frame size of 1120 bytes is larger > > than 1024 bytes [-Wframe-larger-than=] > > 2 arch/mips/configs/ip22_defconfig:71:warning: symbol value 'm' invalid for > > NF_CT_PROTO_UDPLITE > > 2 arch/mips/configs/ip22_defconfig:70:warning: symbol value 'm' invalid for > > NF_CT_PROTO_DCCP > > 1 drivers/mtd/maps/pmcmsp-flash.c:149:30: warning: passing argument 1 of > > 'strncpy' discards 'const' qualifier from pointer target type > > [-Wdiscarded-qualifiers] > > 1 crypto/wp512.c:987:1: warning: the frame size of 1344 bytes is larger > > than 1024 bytes [-Wframe-larger-than=] > > 1 crypto/wp512.c:987:1: warning: the frame size of 1280 bytes is larger > > than 1024 bytes [-Wframe-larger-than=] > > 1 crypto/wp512.c:987:1: warning: the frame size of 1152 bytes is larger > > than 1024 bytes [-Wframe-larger-than=] > > 1 crypto/wp512.c:987:1: warning: the frame size of 1144 bytes is larger > > than 1024 bytes [-Wframe-larger-than=] > > 1 crypto/serpent_generic.c:436:1: warning: the frame size of 1456 bytes is > > larger than 1024 bytes [-Wframe-larger-than=] > > 1 crypto/serpent_generic.c:436:1: warning: the frame size of 1440 bytes is > > larger than 1024 bytes [-Wframe-larger-than=] > > 1 arch/mips/ralink/timer.c:74:13: warning: 'rt_timer_free' defined but not > > used [-Wunused-function] > > 1 arch/mips/ralink/timer.c:104:13: warning: 'rt_timer_disable' defined but > > not used [-Wunused-function] > > 1 arch/mips/ralink/rt305x.c:92:13: warning: 'rt305x_wdt_reset' defined but > > not used [-Wunused-function] > > 1 arch/mips/ralink/prom.c:70:2: warning: 'argv' is used uninitialized in > > this function [-Wuninitialized] > > 1 arch/mips/ralink/prom.c:70:2: warning: 'argc' is used uninitialized in > > this function [-Wuninitialized] > > 1 arch/mips/configs/nlm_xlr_defconfig:93:warning: symbol value 'm' invalid > > for NF_CT_PROTO_UDPLITE > > 1 arch/mips/configs/nlm_xlp_defconfig:113:warning: symbol value 'm' invalid > > for NF_CT_PROTO_UDPLITE > > 1 arch/mips/configs/maltaup_xpa_defconfig:65:warning: symbol value 'm' > > invalid for NF_CT_PROTO_UDPLITE > > 1 arch/mips/configs/maltaup_xpa_defconfig:64:warning: symbol value 'm' > > invalid for NF_CT_PROTO_DCCP > > 1 arch/mips/configs/malta_kvm_defconfig:64:warning: symbol value 'm' > > invalid for NF_CT_PROTO_UDPLITE > > 1 arch/mips/configs/malta_kvm_defconfig:63:warning: symbol value 'm' > > invalid for NF_CT_PROTO_DCCP > > 1 arch/mips/configs/lemote2f_defconfig:42:warning: symbol value 'm' invalid > > for CPU_FREQ_STAT > > These should all be addressed by the set of patches I pointed out in a > previous reply. > > Greg, I'm not sure if you still have the list in your inbox. For now, > I'll monitor the build warnings here, unless you pick the patches or > want me to resend the list I made. Should now be caught up with these, if anything new shows up, please let me know. thanks, greg k-h
Re: stable build: 203 builds: 3 failed, 200 passed, 5 errors, 28 warnings (v4.9.13)
On Tue, Feb 28, 2017 at 02:50:03PM +0100, Arnd Bergmann wrote:
> On Sun, Feb 26, 2017 at 2:52 PM, kernelci.org bot wrote:
> >
> > stable build: 203 builds: 3 failed, 200 passed, 5 errors, 28 warnings
> > (v4.9.13)
>
> Only one warning that doesn't also show up in v4.10-stable
>
> > bcm63xx_defconfig (mips) — PASS, 0 errors, 1 warning, 0 section mismatches
> >
> > Warnings:
> > drivers/net/ethernet/broadcom/bcm63xx_enet.c:1130:3: warning: 'phydev' may
> > be used uninitialized in this function [-Wmaybe-uninitialized]
>
> df384d435a5c ("bcm63xx_enet: avoid uninitialized variable warning")
Also added, thanks.
greg k-h
Re: [PATCH] net: mvneta: support suspend and resume
Hi Jane,
On Wed, 15 Mar 2017 15:08:34 +0800 Jane Li wrote:
> Add basic support for handling suspend and resume.
>
> Signed-off-by: Jane Li
> ---
> drivers/net/ethernet/marvell/mvneta.c | 44
> +++
> 1 file changed, 44 insertions(+)
>
> diff --git a/drivers/net/ethernet/marvell/mvneta.c
> b/drivers/net/ethernet/marvell/mvneta.c
> index 61dd446..4f16342 100644
> --- a/drivers/net/ethernet/marvell/mvneta.c
> +++ b/drivers/net/ethernet/marvell/mvneta.c
> @@ -4405,6 +4405,49 @@ static int mvneta_remove(struct platform_device *pdev)
> return 0;
> }
>
> +#ifdef CONFIG_PM_SLEEP
> +static int mvneta_suspend(struct device *device)
> +{
> + struct net_device *dev = dev_get_drvdata(device);
> + struct mvneta_port *pp = netdev_priv(dev);
> +
> + if (netif_running(dev))
> + mvneta_stop(dev);
> + netif_device_detach(dev);
> + clk_disable_unprepare(pp->clk_bus);
> + clk_disable_unprepare(pp->clk);
> + return 0;
> +}
> +
> +static int mvneta_resume(struct device *device)
> +{
> + struct net_device *dev = dev_get_drvdata(device);
> + struct mvneta_port *pp = netdev_priv(dev);
> + int err;
> +
> + clk_prepare_enable(pp->clk);
> + clk_prepare_enable(pp->clk_bus);
we may miss the necessary registers setting in mvneta_bm_port_init() and
mvneta_conf_mbus_windows(). those registers also need to be restored.
> + mvneta_defaults_set(pp);
before restore the default setting, is it safer to mvneta_port_disable()?
Thanks,
Jisheng
> + err = mvneta_port_power_up(pp, pp->phy_interface);
> + if (err < 0) {
> + dev_err(device, "can't power up port\n");
> + return err;
> + }
> +
> + if (pp->use_inband_status)
> + mvneta_fixed_link_update(pp, dev->phydev);
> +
> + netif_device_attach(dev);
> + if (netif_running(dev))
> + mvneta_open(dev);
> + return 0;
> +}
> +#endif
> +
> +static const struct dev_pm_ops mvneta_pm_ops = {
> + SET_LATE_SYSTEM_SLEEP_PM_OPS(mvneta_suspend, mvneta_resume)
> +};
> +
> static const struct of_device_id mvneta_match[] = {
> { .compatible = "marvell,armada-370-neta" },
> { .compatible = "marvell,armada-xp-neta" },
> @@ -4419,6 +4462,7 @@ static int mvneta_remove(struct platform_device *pdev)
> .driver = {
> .name = MVNETA_DRIVER_NAME,
> .of_match_table = mvneta_match,
> + .pm = &mvneta_pm_ops,
> },
> };
>
Re: [PATCH v2 2/2] can: spi: hi311x: Add Holt HI-311x CAN driver
Hello Akshay,
Am 15.03.2017 um 05:44 schrieb Akshay Bhat:
Hi Wolfgang,
On Tue, Mar 14, 2017 at 2:08 PM, Wolfgang Grandegger
wrote:
...snip
/disconnect cable
can0 2088 [8] 00 00 00 19 00 00 28 00 ERRORFRAME
protocol-violation{{}{acknowledge-slot}}
bus-error
error-counter-tx-rx{{40}{0}}
can0 2088 [8] 00 00 00 19 00 00 58 00 ERRORFRAME
protocol-violation{{}{acknowledge-slot}}
bus-error
error-counter-tx-rx{{88}{0}}
can0 2088 [8] 00 00 00 19 00 00 80 00 ERRORFRAME
protocol-violation{{}{acknowledge-slot}}
bus-error
error-counter-tx-rx{{128}{0}}
TX error warning is missing.
This support was missing in the driver, added in V4 patch.
can0 208C [8] 00 20 00 19 00 00 80 00 ERRORFRAME
controller-problem{tx-error-passive}
protocol-violation{{}{acknowledge-slot}}
bus-error
error-counter-tx-rx{{128}{0}}
Here "tx-error-passiv" is packed with a bus error. What I'm looking for are
state change messages similar to:
can0 2204 [8] 00 08 00 00 00 00 60 00 ERRORFRAME
controller-problem{tx-error-warning}
state-change{tx-error-warning}
error-counter-tx-rx{{96}{0}}
can0 2204 [8] 00 30 00 00 00 00 80 00 ERRORFRAME
controller-problem{tx-error-passive}
state-change{tx-error-passive}
error-counter-tx-rx{{128}{0}
They should always come, even with "berr-reporting off".
HI-3110 has only 1 bus error interrupt. There is no dedicated state
change interrupts like other controllers.
To double check: Could you please read INTF, ERR and STATF at the
beginning of the ISR and print it out (using dev_dbg and fiends). Then
run a test with no cable connected and bus error reporting off.
Wolfgang.
[PATCH v2 2/2] drm/panel: add innolux,p079zca panel driver
Support Innolux P079ZCA 7.85" 768x1024 TFT LCD panel, it is a MIPI DSI
panel.
Signed-off-by: Chris Zhong
---
Changes in v2:
- add some error check
- always use Low power mode to send commend
- add comments for all the sleep
- use DRM_DEV_ERROR instead of dev_err
drivers/gpu/drm/panel/Kconfig | 11 +
drivers/gpu/drm/panel/Makefile| 1 +
drivers/gpu/drm/panel/panel-innolux-p079zca.c | 344 ++
3 files changed, 356 insertions(+)
create mode 100644 drivers/gpu/drm/panel/panel-innolux-p079zca.c
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 62aba97..99dd010 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -18,6 +18,17 @@ config DRM_PANEL_SIMPLE
that it can be automatically turned off when the panel goes into a
low power state.
+config DRM_PANEL_INNOLUX_P079ZCA
+ tristate "Innolux P079ZCA panel"
+ depends on OF
+ depends on DRM_MIPI_DSI
+ depends on BACKLIGHT_CLASS_DEVICE
+ help
+ Say Y here if you want to enable support for Innolux P079ZCA
+ TFT-LCD modules. The panel has a 1024x768 resolution and uses
+ 24 bit RGB per pixel. It provides a MIPI DSI interface to
+ the host and has a built-in LED backlight.
+
config DRM_PANEL_JDI_LT070ME05000
tristate "JDI LT070ME05000 WUXGA DSI panel"
depends on OF
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index a5c7ec0..bda2aa4 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -1,4 +1,5 @@
obj-$(CONFIG_DRM_PANEL_SIMPLE) += panel-simple.o
+obj-$(CONFIG_DRM_PANEL_INNOLUX_P079ZCA) += panel-innolux-p079zca.o
obj-$(CONFIG_DRM_PANEL_JDI_LT070ME05000) += panel-jdi-lt070me05000.o
obj-$(CONFIG_DRM_PANEL_LG_LG4573) += panel-lg-lg4573.o
obj-$(CONFIG_DRM_PANEL_PANASONIC_VVX10F034N00) +=
panel-panasonic-vvx10f034n00.o
diff --git a/drivers/gpu/drm/panel/panel-innolux-p079zca.c
b/drivers/gpu/drm/panel/panel-innolux-p079zca.c
new file mode 100644
index 000..b8c34e0
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-innolux-p079zca.c
@@ -0,0 +1,344 @@
+/*
+ * Copyright (c) 2017, Fuzhou Rockchip Electronics Co., Ltd
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+
+#include
+
+struct innolux_panel {
+ struct drm_panel base;
+ struct mipi_dsi_device *link;
+
+ struct backlight_device *backlight;
+ struct regulator *supply;
+ struct gpio_desc *enable_gpio;
+
+ bool prepared;
+ bool enabled;
+};
+
+static inline struct innolux_panel *to_innolux_panel(struct drm_panel *panel)
+{
+ return container_of(panel, struct innolux_panel, base);
+}
+
+static int innolux_panel_disable(struct drm_panel *panel)
+{
+ struct innolux_panel *innolux = to_innolux_panel(panel);
+ int err;
+
+ if (!innolux->enabled)
+ return 0;
+
+ if (innolux->backlight) {
+ innolux->backlight->props.power = FB_BLANK_POWERDOWN;
+ backlight_update_status(innolux->backlight);
+ }
+
+ err = mipi_dsi_dcs_set_display_off(innolux->link);
+ if (err < 0)
+ DRM_DEV_ERROR(panel->dev, "failed to set display off: %d\n",
+ err);
+
+ innolux->enabled = false;
+
+ return 0;
+}
+
+static int innolux_panel_unprepare(struct drm_panel *panel)
+{
+ struct innolux_panel *innolux = to_innolux_panel(panel);
+ int err;
+
+ if (!innolux->prepared)
+ return 0;
+
+ err = mipi_dsi_dcs_enter_sleep_mode(innolux->link);
+ if (err < 0) {
+ DRM_DEV_ERROR(panel->dev, "failed to enter sleep mode: %d\n",
+ err);
+ return err;
+ }
+
+ gpiod_set_value_cansleep(innolux->enable_gpio, 0);
+
+ /* T8: 80ms - 1000ms */
+ msleep(80);
+
+ err = regulator_disable(innolux->supply);
+ if (err < 0)
+ return err;
+
+ innolux->prepared = false;
+
+ return 0;
+}
+
+static int innolux_panel_prepare(struct drm_panel *panel)
+{
+ struct innolux_panel *innolux = to_innolux_panel(panel);
+ int err, ret;
+
+ if (innolux->prepared)
+ return 0;
+
+ gpiod_set_value_cansleep(innolux->enable_gpio, 0);
+
+ err = regulator_enable(innolux->supply);
+ if (err < 0)
+ return err;
+
+ /* T2: 15ms - 1000ms */
+ usleep_range(15000, 16000);
+
+ gpiod_set_value_cansleep(innolux->enable_gpio, 1);
+
+ /* T4: 15ms - 1000ms */
+ usleep_range(15000, 16000);
+
+
[PATCH v2 1/2] dt-bindings: Add INNOLUX P079ZCA panel bindings
The Innolux P079ZCA is a 7.85" panel with a 768X1024 resolution and
connected to DSI using four lanes.
Signed-off-by: Chris Zhong
---
Changes in v2: None
.../bindings/display/panel/innolux,p079zca.txt | 23 ++
1 file changed, 23 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/innolux,p079zca.txt
diff --git
a/Documentation/devicetree/bindings/display/panel/innolux,p079zca.txt
b/Documentation/devicetree/bindings/display/panel/innolux,p079zca.txt
new file mode 100644
index 000..5c70a83
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/innolux,p079zca.txt
@@ -0,0 +1,23 @@
+Innolux P079ZCA 7.85" 768x1024 TFT LCD panel
+
+Required properties:
+- compatible: should be "innolux,p079zca"
+- reg: DSI virtual channel of the peripheral
+- power-supply: phandle of the regulator that provides the supply voltage
+- enable-gpios: panel enable gpio
+
+Optional properties:
+- backlight: phandle of the backlight device attached to the panel
+
+Example:
+
+ &mipi_dsi {
+ panel {
+ compatible = "innolux,p079zca";
+ reg = <0>;
+ power-supply = <...>;
+ backlight = <&backlight>;
+ enable-gpios = <&gpio1 13 GPIO_ACTIVE_HIGH>;
+ status = "okay";
+ };
+ };
--
2.6.3
Re: [PATCH 4/4] drm/amdgpu: resize VRAM BAR for CPU access
Is it possible on Carrizo asics? Or only supports on newer asics?
On Mon, Mar 13, 2017 at 6:11 PM, Christian König
wrote:
> From: Christian König
>
> Try to resize BAR0 to let CPU access all of VRAM.
>
> Signed-off-by: Christian König
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu.h| 1 +
> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 29 +
> drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c | 8 +---
> drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c | 8 +---
> 4 files changed, 40 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> index 3b81ded..905ded9 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> @@ -1719,6 +1719,7 @@ uint64_t amdgpu_ttm_tt_pte_flags(struct amdgpu_device
> *adev, struct ttm_tt *ttm,
> struct ttm_mem_reg *mem);
> void amdgpu_vram_location(struct amdgpu_device *adev, struct amdgpu_mc *mc,
> u64 base);
> void amdgpu_gtt_location(struct amdgpu_device *adev, struct amdgpu_mc *mc);
> +void amdgpu_resize_bar0(struct amdgpu_device *adev);
> void amdgpu_ttm_set_active_vram_size(struct amdgpu_device *adev, u64 size);
> int amdgpu_ttm_init(struct amdgpu_device *adev);
> void amdgpu_ttm_fini(struct amdgpu_device *adev);
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> index 118f4e6..92955fe 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> @@ -692,6 +692,35 @@ void amdgpu_gtt_location(struct amdgpu_device *adev,
> struct amdgpu_mc *mc)
> mc->gtt_size >> 20, mc->gtt_start, mc->gtt_end);
> }
>
> +/**
> + * amdgpu_resize_bar0 - try to resize BAR0
> + *
> + * @adev: amdgpu_device pointer
> + *
> + * Try to resize BAR0 to make all VRAM CPU accessible.
> + */
> +void amdgpu_resize_bar0(struct amdgpu_device *adev)
> +{
> + u32 size = max(ilog2(adev->mc.real_vram_size - 1) + 1, 20) - 20;
> + int r;
> +
> + r = pci_resize_resource(adev->pdev, 0, size);
> +
> + if (r == -ENOTSUPP) {
> + /* The hardware don't support the extension. */
> + return;
> +
> + } else if (r == -ENOSPC) {
> + DRM_INFO("Not enoigh PCI address space for a large BAR.");
> + } else if (r) {
> + DRM_ERROR("Problem resizing BAR0 (%d).", r);
> + }
> +
> + /* Reinit the doorbell mapping, it is most likely moved as well */
> + amdgpu_doorbell_fini(adev);
> + BUG_ON(amdgpu_doorbell_init(adev));
> +}
> +
> /*
> * GPU helpers function.
> */
> diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
> b/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
> index dc9b6d6..36a7aa5 100644
> --- a/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
> @@ -367,13 +367,15 @@ static int gmc_v7_0_mc_init(struct amdgpu_device *adev)
> break;
> }
> adev->mc.vram_width = numchan * chansize;
> - /* Could aper size report 0 ? */
> - adev->mc.aper_base = pci_resource_start(adev->pdev, 0);
> - adev->mc.aper_size = pci_resource_len(adev->pdev, 0);
> /* size in MB on si */
> adev->mc.mc_vram_size = RREG32(mmCONFIG_MEMSIZE) * 1024ULL * 1024ULL;
> adev->mc.real_vram_size = RREG32(mmCONFIG_MEMSIZE) * 1024ULL *
> 1024ULL;
>
> + if (!(adev->flags & AMD_IS_APU))
> + amdgpu_resize_bar0(adev);
> + adev->mc.aper_base = pci_resource_start(adev->pdev, 0);
> + adev->mc.aper_size = pci_resource_len(adev->pdev, 0);
> +
> #ifdef CONFIG_X86_64
> if (adev->flags & AMD_IS_APU) {
> adev->mc.aper_base = ((u64)RREG32(mmMC_VM_FB_OFFSET)) << 22;
> diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
> b/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
> index c087b00..7761ad3 100644
> --- a/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
> @@ -459,13 +459,15 @@ static int gmc_v8_0_mc_init(struct amdgpu_device *adev)
> break;
> }
> adev->mc.vram_width = numchan * chansize;
> - /* Could aper size report 0 ? */
> - adev->mc.aper_base = pci_resource_start(adev->pdev, 0);
> - adev->mc.aper_size = pci_resource_len(adev->pdev, 0);
> /* size in MB on si */
> adev->mc.mc_vram_size = RREG32(mmCONFIG_MEMSIZE) * 1024ULL * 1024ULL;
> adev->mc.real_vram_size = RREG32(mmCONFIG_MEMSIZE) * 1024ULL *
> 1024ULL;
>
> + if (!(adev->flags & AMD_IS_APU))
> + amdgpu_resize_bar0(adev);
> + adev->mc.aper_base = pci_resource_start(adev->pdev, 0);
> + adev->mc.aper_size = pci_resource_len(adev->pdev, 0);
> +
> #ifdef CONFIG_X86_64
> if (adev->flags & AMD_IS_APU) {
> adev->mc.aper_base = ((u64)RREG32(mmMC_VM_FB_OFFSET)) << 22;
> --
> 2.7.4
>
> _
[PATCH v5 0/3] Use data tune for CMD line tune
yong mao (3): mmc: dt-bindings: update Mediatek MMC bindings ARM64: dts: mediatek: configure some fixed mmc parameters mmc: mediatek: Use data tune for CMD line tune Documentation/devicetree/bindings/mmc/mtk-sd.txt | 12 ++ arch/arm64/boot/dts/mediatek/mt8173-evb.dts | 3 + drivers/mmc/host/mtk-sd.c| 168 --- 3 files changed, 167 insertions(+), 16 deletions(-) -- 1.8.1.1.dirty
[PATCH v5 3/3] mmc: mediatek: Use data tune for CMD line tune
From: yong mao
If we don't select a set of better parameters for our emmc host,
It may easily occur CMD response CRC error. And also it may cause
cannot boot up issue.
Fot getting a set of better parameters, our emmc host supports
data tune mechanism.Therefore, our emmc driver also should change
to use data tune for CMD line.
Because our emmc host use the different clock source to sample the
CMD signal between HS200 and HS400 mode, the parameters are also
different between these two modes.
Separate cmd internal delay for HS200/HS400 mode.
This change can fix "System can not boot up" issue.
Signed-off-by: Yong Mao
Signed-off-by: Chaotian Jing
---
drivers/mmc/host/mtk-sd.c | 168 -
1 file changed, 152 insertions(+), 16 deletions(-)
diff --git a/drivers/mmc/host/mtk-sd.c b/drivers/mmc/host/mtk-sd.c
index 80ba034..07f3236 100644
--- a/drivers/mmc/host/mtk-sd.c
+++ b/drivers/mmc/host/mtk-sd.c
@@ -75,6 +75,7 @@
#define MSDC_PATCH_BIT1 0xb4
#define MSDC_PAD_TUNE0xec
#define PAD_DS_TUNE 0x188
+#define PAD_CMD_TUNE 0x18c
#define EMMC50_CFG0 0x208
/*--*/
@@ -210,13 +211,18 @@
#define MSDC_PATCH_BIT_SPCPUSH(0x1 << 29) /* RW */
#define MSDC_PATCH_BIT_DECRCTMO (0x1 << 30) /* RW */
+#define MSDC_PAD_TUNE_DATWRDLY (0x1f << 0) /* RW */
#define MSDC_PAD_TUNE_DATRRDLY (0x1f << 8) /* RW */
#define MSDC_PAD_TUNE_CMDRDLY(0x1f << 16) /* RW */
+#define MSDC_PAD_TUNE_CMDRRDLY (0x1f << 22) /* RW */
+#define MSDC_PAD_TUNE_CLKTDLY(0x1f << 27) /* RW */
#define PAD_DS_TUNE_DLY1 (0x1f << 2) /* RW */
#define PAD_DS_TUNE_DLY2 (0x1f << 7) /* RW */
#define PAD_DS_TUNE_DLY3 (0x1f << 12) /* RW */
+#define PAD_CMD_TUNE_RX_DLY3 (0x1f << 1) /* RW */
+
#define EMMC50_CFG_PADCMD_LATCHCK (0x1 << 0) /* RW */
#define EMMC50_CFG_CRCSTS_EDGE(0x1 << 3) /* RW */
#define EMMC50_CFG_CFCSTS_SEL (0x1 << 4) /* RW */
@@ -284,12 +290,14 @@ struct msdc_save_para {
u32 patch_bit0;
u32 patch_bit1;
u32 pad_ds_tune;
+ u32 pad_cmd_tune;
u32 emmc50_cfg0;
};
struct msdc_tune_para {
u32 iocon;
u32 pad_tune;
+ u32 pad_cmd_tune;
};
struct msdc_delay_phase {
@@ -331,6 +339,10 @@ struct msdc_host {
unsigned char timing;
bool vqmmc_enabled;
u32 hs400_ds_delay;
+ u32 hs200_cmd_int_delay; /* cmd internal delay for HS200/SDR104 */
+ u32 hs400_cmd_int_delay; /* cmd internal delay for HS400 */
+ bool hs400_cmd_resp_sel_rising;
+/* cmd response sample selection for HS400 */
bool hs400_mode;/* current eMMC will run at hs400 mode */
struct msdc_save_para save_para; /* used when gate HCLK */
struct msdc_tune_para def_tune_para; /* default tune setting */
@@ -600,8 +612,14 @@ static void msdc_set_mclk(struct msdc_host *host, unsigned
char timing, u32 hz)
} else {
writel(host->saved_tune_para.iocon, host->base + MSDC_IOCON);
writel(host->saved_tune_para.pad_tune, host->base +
MSDC_PAD_TUNE);
+ writel(host->saved_tune_para.pad_cmd_tune,
+ host->base + PAD_CMD_TUNE);
}
+ if (timing == MMC_TIMING_MMC_HS400)
+ sdr_set_field(host->base + PAD_CMD_TUNE,
+ MSDC_PAD_TUNE_CMDRRDLY,
+ host->hs400_cmd_int_delay);
dev_dbg(host->dev, "sclk: %d, timing: %d\n", host->sclk, timing);
}
@@ -1302,7 +1320,7 @@ static struct msdc_delay_phase get_best_delay(struct
msdc_host *host, u32 delay)
len_final = len;
}
start += len ? len : 1;
- if (len >= 8 && start_final < 4)
+ if (len >= 12 && start_final < 4)
break;
}
@@ -1325,36 +1343,67 @@ static int msdc_tune_response(struct mmc_host *mmc, u32
opcode)
struct msdc_host *host = mmc_priv(mmc);
u32 rise_delay = 0, fall_delay = 0;
struct msdc_delay_phase final_rise_delay, final_fall_delay = { 0,};
+ struct msdc_delay_phase internal_delay_phase;
u8 final_delay, final_maxlen;
+ u32 internal_delay = 0;
int cmd_err;
- int i;
+ int i, j;
+
+ if (mmc->ios.timing == MMC_TIMING_MMC_HS200 ||
+ mmc->ios.timing == MMC_TIMING_UHS_SDR104)
+ sdr_set_field(host->base + MSDC_PAD_TUNE,
+ MSDC_PAD_TUNE_CMDRRDLY,
+ host->hs200_cmd_int_delay);
sdr_clr_bits(host->base + MSDC_IOCON, MSDC_IOCON_RSPL);
for (i = 0 ; i < PAD_DELAY_MAX; i++) {
sdr_set_field(host->base + MSDC_PAD_TUNE,
MSDC_PAD_TUNE_CMDRDLY, i);
- mmc_send_tuning(mmc, opcode, &cmd_err);
-
[PATCH v5 1/3] mmc: dt-bindings: update Mediatek MMC bindings
From: yong mao
Add description for mediatek,hs200-cmd-int-delay
Add description for mediatek,hs400-cmd-int-delay
Add description for mediatek,hs400-cmd-resp-sel-rising
Signed-off-by: Yong Mao
---
Documentation/devicetree/bindings/mmc/mtk-sd.txt | 12
1 file changed, 12 insertions(+)
diff --git a/Documentation/devicetree/bindings/mmc/mtk-sd.txt
b/Documentation/devicetree/bindings/mmc/mtk-sd.txt
index 0120c7f..4182ea3 100644
--- a/Documentation/devicetree/bindings/mmc/mtk-sd.txt
+++ b/Documentation/devicetree/bindings/mmc/mtk-sd.txt
@@ -21,6 +21,15 @@ Optional properties:
- assigned-clocks: PLL of the source clock
- assigned-clock-parents: parent of source clock, used for HS400 mode to get
400Mhz source clock
- hs400-ds-delay: HS400 DS delay setting
+- mediatek,hs200-cmd-int-delay: HS200 command internal delay setting.
+ This field has total 32 stages.
+ The value is an integer from 0 to 31.
+- mediatek,hs400-cmd-int-delay: HS400 command internal delay setting
+ This field has total 32 stages.
+ The value is an integer from 0 to 31.
+- mediatek,hs400-cmd-resp-sel-rising: HS400 command response sample selection
+ If present,HS400 command responses are
sampled on rising edges.
+ If not present,HS400 command responses
are sampled on falling edges.
Examples:
mmc0: mmc@1123 {
@@ -38,4 +47,7 @@ mmc0: mmc@1123 {
assigned-clocks = <&topckgen CLK_TOP_MSDC50_0_SEL>;
assigned-clock-parents = <&topckgen CLK_TOP_MSDCPLL_D2>;
hs400-ds-delay = <0x14015>;
+ mediatek,hs200-cmd-int-delay = <26>;
+ mediatek,hs400-cmd-int-delay = <14>;
+ mediatek,hs400-cmd-resp-sel-rising;
};
--
1.7.9.5
Re: [PATCH v2 04/10] mm: make the try_to_munlock void function
On 03/15/2017 06:24 AM, Minchan Kim wrote: > try_to_munlock returns SWAP_MLOCK if the one of VMAs mapped > the page has VM_LOCKED flag. In that time, VM set PG_mlocked to > the page if the page is not pte-mapped THP which cannot be > mlocked, either. > > With that, __munlock_isolated_page can use PageMlocked to check > whether try_to_munlock is successful or not without relying on > try_to_munlock's retval. It helps to make try_to_unmap/try_to_unmap_one > simple with upcoming patches. > > Cc: Vlastimil Babka > Acked-by: Kirill A. Shutemov > Signed-off-by: Minchan Kim Acked-by: Vlastimil Babka
[PATCH v5 2/3] ARM64: dts: mediatek: configure some fixed mmc parameters
From: yong mao configure some fixed mmc parameters Signed-off-by: Yong Mao Signed-off-by: Chaotian Jing --- arch/arm64/boot/dts/mediatek/mt8173-evb.dts |3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/arm64/boot/dts/mediatek/mt8173-evb.dts b/arch/arm64/boot/dts/mediatek/mt8173-evb.dts index 0ecaad4..1c3634f 100644 --- a/arch/arm64/boot/dts/mediatek/mt8173-evb.dts +++ b/arch/arm64/boot/dts/mediatek/mt8173-evb.dts @@ -134,6 +134,9 @@ bus-width = <8>; max-frequency = <5000>; cap-mmc-highspeed; + mediatek,hs200-cmd-int-delay=<26>; + mediatek,hs400-cmd-int-delay=<14>; + mediatek,hs400-cmd-resp-sel-rising; vmmc-supply = <&mt6397_vemc_3v3_reg>; vqmmc-supply = <&mt6397_vio18_reg>; non-removable; -- 1.7.9.5
Re: [PATCH] drm/exynos: Print kernel pointers in a restricted form
Hi Tobias, On 14.03.2017 21:41, Tobias Jakobi wrote: > Krzysztof Kozlowski wrote: >> On Tue, Mar 14, 2017 at 08:17:35PM +0100, Tobias Jakobi wrote: >>> Krzysztof Kozlowski wrote: On Tue, Mar 14, 2017 at 08:01:41PM +0100, Tobias Jakobi wrote: > Hello Krzysztof, > > I was wondering about the benefit of this. From a quick look these are > all messages that end up in the kernel log / dmesg. > > IIRC %pK does nothing there, since dmest_restrict is supposed to be used > to deny an unpriviliged user the access to the kernel log. > > Or am I missing something here? These are regular printks so depending on kernel options (e.g. dynamic debug, drm.debug) these might be printed also in the console. Of course we could argue then if access to one of the consoles is worth securing. >>> This here suggests otherwise. >>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/sysctl/kernel.txt#n388 >>> >>> I have not tested this, but IIRC %pK is not honored by the kernel >>> logging infrastucture. That's why dmesg_restrict is there. >>> >>> Correct me if I'm wrong. >> The %pK will not help for dmesg or /proc/kmsg but it will help for >> console (/dev/ttySACN, ttySN etc) because effectively it uses the same >> vsprintf()/pointer() functions. > Thanks for the explanation, I didn't know that there was a difference > there. In that case, looks good to me. > > Just to clarify %pK: Documentation/printk-formats.txt: %pK 0x01234567 or 0x0123456789abcdef For printing kernel pointers which should be hidden from unprivileged users. The behaviour of %pK depends on the kptr_restrict sysctl - see Documentation/sysctl/kernel.txt for more details. Documentation/sysctl/kernel.txt: kptr_restrict: This toggle indicates whether restrictions are placed on exposing kernel addresses via /proc and other interfaces. When kptr_restrict is set to (0), the default, there are no restrictions. When kptr_restrict is set to (1), kernel pointers printed using the %pK format specifier will be replaced with 0's unless the user has CAP_SYSLOG and effective user and group ids are equal to the real ids. This is because %pK checks are done at read() time rather than open() time, so if permissions are elevated between the open() and the read() (e.g via a setuid binary) then %pK will not leak kernel pointers to unprivileged users. Note, this is a temporary solution only. The correct long-term solution is to do the permission checks at open() time. Consider removing world read permissions from files that use %pK, and using dmesg_restrict to protect against uses of %pK in dmesg(8) if leaking kernel pointer values to unprivileged users is a concern. When kptr_restrict is set to (2), kernel pointers printed using %pK will be replaced with 0's regardless of privileges. --- Regards Andrzej
Re: [PATCH 4.4 17/25] USB: serial: digi_acceleport: fix OOB data sanity check
On Mon, Mar 13, 2017 at 06:14:37PM +0100, Johan Hovold wrote:
> On Fri, Feb 24, 2017 at 06:55:02PM +0100, Greg Kroah-Hartman wrote:
> > On Fri, Feb 24, 2017 at 06:33:04PM +0100, Johan Hovold wrote:
> > > On Fri, Feb 24, 2017 at 01:38:25PM +, Ben Hutchings wrote: > On Fri,
> > > 2017-02-24 at 09:25 +0100, Greg Kroah-Hartman wrote:
> > > > > 4.4-stable review patch. If anyone has any objections, please let me
> > > > > know.
> > > > >
> > > > > --
> > > > >
> > > > > From: Johan Hovold
> > > > >
> > > > > commit 2d380889215fe20b8523345649dee0579821800c upstream.
> > > > >
> > > > > Make sure to check for short transfers to avoid underflow in a loop
> > > > > condition when parsing the receive buffer.
> > > > >
> > > > > Also fix an off-by-one error in the incomplete sanity check which
> > > > > could
> > > > > lead to invalid data being parsed.
> > > >
> > > > This appears to *introduce* an off-by-one. Which is not as serious as
> > > > the underflow, but is still a regression.
> > > >
> > > > Suppose we have urb->actual_length == 4:
> > > >
> > > > [...]
> > > > > - for (i = 0; i < urb->actual_length - 3;) {
> > > >
> > > > i < 1 is true, so we would run the loop once.
> > > >
> > > > > - opcode = ((unsigned char *)urb->transfer_buffer)[i++];
> > > > > - line = ((unsigned char *)urb->transfer_buffer)[i++];
> > > > > - status = ((unsigned char *)urb->transfer_buffer)[i++];
> > > > > - val = ((unsigned char *)urb->transfer_buffer)[i++];
> > > > > + for (i = 0; i < urb->actual_length - 4; i += 4) {
> > > >
> > > > i < 0 is false, so we now skip the loop.
> > >
> > > Good catch, thanks! The original loop condition was indeed correct
> > > (modulo the missing underflow check), and I'll post a follow-up fix to
> > > address this.
> > >
> > > > > + opcode = buf[i];
> > > > > + line = buf[i + 1];
> > > > > + status = buf[i + 2];
> > > > > + val = buf[i + 3];
> > >
> > > You should probably not apply this one until after the follow-up is in
> > > Linus' tree as this patch breaks TIOCMGET.
> >
> > Ok, I'll drop this one from the stable tree now. Remind me to pick this
> > one up when the fixup hits Linus's tree.
>
> The follow-up fix is now in Linus's tree so both this one:
>
> 2d380889215f ("USB: serial: digi_acceleport: fix OOB data sanity check")
>
> and the follow-up:
>
> 2e46565cf622 ("USB: serial: digi_acceleport: fix OOB-event processing")
>
> can now be applied to the stable trees.
Thanks, now queued up.
greg k-h
Re: [PATCH 4/4] drm/amdgpu: resize VRAM BAR for CPU access
Carizzo is an APU and resizing BARs isn't needed nor supported there.
The CPU can access the full stolen VRAM directly on that hardware.
As far as I know ASICs with support for this are Tonga, Fiji and all
Polaris variants.
Christian.
Am 15.03.2017 um 08:23 schrieb Ayyappa Ch:
Is it possible on Carrizo asics? Or only supports on newer asics?
On Mon, Mar 13, 2017 at 6:11 PM, Christian König
wrote:
From: Christian König
Try to resize BAR0 to let CPU access all of VRAM.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h| 1 +
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 29 +
drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c | 8 +---
drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c | 8 +---
4 files changed, 40 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index 3b81ded..905ded9 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -1719,6 +1719,7 @@ uint64_t amdgpu_ttm_tt_pte_flags(struct amdgpu_device
*adev, struct ttm_tt *ttm,
struct ttm_mem_reg *mem);
void amdgpu_vram_location(struct amdgpu_device *adev, struct amdgpu_mc *mc,
u64 base);
void amdgpu_gtt_location(struct amdgpu_device *adev, struct amdgpu_mc *mc);
+void amdgpu_resize_bar0(struct amdgpu_device *adev);
void amdgpu_ttm_set_active_vram_size(struct amdgpu_device *adev, u64 size);
int amdgpu_ttm_init(struct amdgpu_device *adev);
void amdgpu_ttm_fini(struct amdgpu_device *adev);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index 118f4e6..92955fe 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -692,6 +692,35 @@ void amdgpu_gtt_location(struct amdgpu_device *adev,
struct amdgpu_mc *mc)
mc->gtt_size >> 20, mc->gtt_start, mc->gtt_end);
}
+/**
+ * amdgpu_resize_bar0 - try to resize BAR0
+ *
+ * @adev: amdgpu_device pointer
+ *
+ * Try to resize BAR0 to make all VRAM CPU accessible.
+ */
+void amdgpu_resize_bar0(struct amdgpu_device *adev)
+{
+ u32 size = max(ilog2(adev->mc.real_vram_size - 1) + 1, 20) - 20;
+ int r;
+
+ r = pci_resize_resource(adev->pdev, 0, size);
+
+ if (r == -ENOTSUPP) {
+ /* The hardware don't support the extension. */
+ return;
+
+ } else if (r == -ENOSPC) {
+ DRM_INFO("Not enoigh PCI address space for a large BAR.");
+ } else if (r) {
+ DRM_ERROR("Problem resizing BAR0 (%d).", r);
+ }
+
+ /* Reinit the doorbell mapping, it is most likely moved as well */
+ amdgpu_doorbell_fini(adev);
+ BUG_ON(amdgpu_doorbell_init(adev));
+}
+
/*
* GPU helpers function.
*/
diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
b/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
index dc9b6d6..36a7aa5 100644
--- a/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
@@ -367,13 +367,15 @@ static int gmc_v7_0_mc_init(struct amdgpu_device *adev)
break;
}
adev->mc.vram_width = numchan * chansize;
- /* Could aper size report 0 ? */
- adev->mc.aper_base = pci_resource_start(adev->pdev, 0);
- adev->mc.aper_size = pci_resource_len(adev->pdev, 0);
/* size in MB on si */
adev->mc.mc_vram_size = RREG32(mmCONFIG_MEMSIZE) * 1024ULL * 1024ULL;
adev->mc.real_vram_size = RREG32(mmCONFIG_MEMSIZE) * 1024ULL * 1024ULL;
+ if (!(adev->flags & AMD_IS_APU))
+ amdgpu_resize_bar0(adev);
+ adev->mc.aper_base = pci_resource_start(adev->pdev, 0);
+ adev->mc.aper_size = pci_resource_len(adev->pdev, 0);
+
#ifdef CONFIG_X86_64
if (adev->flags & AMD_IS_APU) {
adev->mc.aper_base = ((u64)RREG32(mmMC_VM_FB_OFFSET)) << 22;
diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
b/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
index c087b00..7761ad3 100644
--- a/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
@@ -459,13 +459,15 @@ static int gmc_v8_0_mc_init(struct amdgpu_device *adev)
break;
}
adev->mc.vram_width = numchan * chansize;
- /* Could aper size report 0 ? */
- adev->mc.aper_base = pci_resource_start(adev->pdev, 0);
- adev->mc.aper_size = pci_resource_len(adev->pdev, 0);
/* size in MB on si */
adev->mc.mc_vram_size = RREG32(mmCONFIG_MEMSIZE) * 1024ULL * 1024ULL;
adev->mc.real_vram_size = RREG32(mmCONFIG_MEMSIZE) * 1024ULL * 1024ULL;
+ if (!(adev->flags & AMD_IS_APU))
+ amdgpu_resize_bar0(adev);
+ adev->mc.aper_base = pci_resource_start(adev->pdev, 0);
+ adev->mc.aper_size = pci_resource_len(adev->pdev, 0);
+
#ifdef CONFIG_X86_64
if (adev->flags & AMD_IS_APU) {
adev->mc
Re: [PATCH] mm: move pcp and lru-pcp drainging into single wq
On Tue 14-03-17 18:07:38, Yang Li wrote:
> On Mon, Mar 13, 2017 at 4:58 AM, Michal Hocko wrote:
> > On Fri 10-03-17 17:31:56, Yang Li wrote:
> >> On Tue, Mar 7, 2017 at 7:17 AM, Michal Hocko wrote:
> >> > From: Michal Hocko
> >> >
> >> > We currently have 2 specific WQ_RECLAIM workqueues in the mm code.
> >> > vmstat_wq for updating pcp stats and lru_add_drain_wq dedicated to drain
> >> > per cpu lru caches. This seems more than necessary because both can run
> >> > on a single WQ. Both do not block on locks requiring a memory allocation
> >> > nor perform any allocations themselves. We will save one rescuer thread
> >> > this way.
> >> >
> >> > On the other hand drain_all_pages() queues work on the system wq which
> >> > doesn't have rescuer and so this depend on memory allocation (when all
> >> > workers are stuck allocating and new ones cannot be created). This is
> >> > not critical as there should be somebody invoking the OOM killer (e.g.
> >> > the forking worker) and get the situation unstuck and eventually
> >> > performs the draining. Quite annoying though. This worker should be
> >> > using WQ_RECLAIM as well. We can reuse the same one as for lru draining
> >> > and vmstat.
> >> >
> >> > Changes since v1
> >> > - rename vmstat_wq to mm_percpu_wq - per Mel
> >> > - make sure we are not trying to enqueue anything while the WQ hasn't
> >> > been intialized yet. This shouldn't happen because the initialization
> >> > is done from an init code but some init section might be triggering
> >> > those paths indirectly so just warn and skip the draining in that case
> >> > per Vlastimil
> >>
> >> So what's the plan if this really happens? Shall we put the
> >> initialization of the mm_percpu_wq earlier?
> >
> > yes
> >
> >> Or if it is really harmless we can probably remove the warnings.
> >
> > Yeah, it is harmless but if we can move it earlier then it would be
> > prefferable to fix this.
> >
> >>
> >> I'm seeing this on arm64 with a linux-next tree:
> > [...]
> >> [0.279000] [] drain_all_pages+0x244/0x25c
> >> [0.279065] [] start_isolate_page_range+0x14c/0x1f0
> >> [0.279137] [] alloc_contig_range+0xec/0x354
> >> [0.279203] [] cma_alloc+0x100/0x1fc
> >> [0.279263] [] dma_alloc_from_contiguous+0x3c/0x44
> >> [0.279336] [] atomic_pool_init+0x7c/0x208
> >> [0.279399] [] arm64_dma_init+0x44/0x4c
> >> [0.279461] [] do_one_initcall+0x38/0x128
> >> [0.279525] [] kernel_init_freeable+0x1a0/0x240
> >> [0.279596] [] kernel_init+0x10/0xfc
> >> [0.279654] [] ret_from_fork+0x10/0x20
> >
> > The following should address this. I didn't get to test it yet though.
> > ---
> > diff --git a/include/linux/mm.h b/include/linux/mm.h
> > index 21ee5503c702..8362dca071cb 100644
> > --- a/include/linux/mm.h
> > +++ b/include/linux/mm.h
> > @@ -32,6 +32,8 @@ struct user_struct;
> > struct writeback_control;
> > struct bdi_writeback;
> >
> > +void init_mm_internals(void);
> > +
> > #ifndef CONFIG_NEED_MULTIPLE_NODES /* Don't use mapnrs, do it properly
> > */
> > extern unsigned long max_mapnr;
> >
> > diff --git a/init/main.c b/init/main.c
> > index 51aa8f336819..c72d35250e84 100644
> > --- a/init/main.c
> > +++ b/init/main.c
> > @@ -1023,6 +1023,8 @@ static noinline void __init kernel_init_freeable(void)
> >
> > workqueue_init();
> >
> > + init_mm_internals();
> > +
> > do_pre_smp_initcalls();
> > lockup_detector_init();
> >
> > diff --git a/mm/vmstat.c b/mm/vmstat.c
> > index 4bbc775f9d08..d0871fc1aeca 100644
> > --- a/mm/vmstat.c
> > +++ b/mm/vmstat.c
> > @@ -1762,7 +1762,7 @@ static int vmstat_cpu_dead(unsigned int cpu)
> >
> > struct workqueue_struct *mm_percpu_wq;
> >
> > -static int __init setup_vmstat(void)
> > +void __init init_mm_internals(void)
> > {
> > int ret __maybe_unused;
> >
> > @@ -1792,9 +1792,7 @@ static int __init setup_vmstat(void)
> > proc_create("vmstat", S_IRUGO, NULL, &proc_vmstat_file_operations);
> > proc_create("zoneinfo", S_IRUGO, NULL,
> > &proc_zoneinfo_file_operations);
> > #endif
> > - return 0;
> > }
> > -module_init(setup_vmstat)
> >
> > #if defined(CONFIG_DEBUG_FS) && defined(CONFIG_COMPACTION)
>
> I did a test on arm64. This do fix the warnings.
Thanks! Can I assume your
Tested-by: Yang Li
--
Michal Hocko
SUSE Labs
Re: [linux-sunxi] [PATCH v3 3/5] ARM: dts: sun8i: h3: add usb_otg and OHCI/EHCI for usbc0 on H3
On Tue, Mar 7, 2017 at 6:34 AM, Icenowy Zheng wrote: > Allwinner H3 have a dual-routed USB PHY0 -- routed to either OHCI/EHCI > or MUSB controller. > > Add device nodes for these controllers. > > Signed-off-by: Icenowy Zheng Acked-by: Chen-Yu Tsai
Re: [PATCH] sched/deadline: Add missing update_rq_clock() in dl_task_timer()
Ping, :) 2017-03-07 13:51 GMT+08:00 Wanpeng Li : > From: Wanpeng Li > > The following warning can be triggered by hot-unplugging the CPU > on which an active SCHED_DEADLINE task is running on: > > [ cut here ] > WARNING: CPU: 7 PID: 0 at kernel/sched/sched.h:833 > replenish_dl_entity+0x71e/0xc40 > rq->clock_update_flags < RQCF_ACT_SKIP > CPU: 7 PID: 0 Comm: swapper/7 Tainted: GB 4.11.0-rc1+ #24 > Hardware name: LENOVO ThinkCentre M8500t-N000/SHARKBAY, BIOS FBKTC1AUS > 02/16/2016 > Call Trace: > > dump_stack+0x85/0xc4 > __warn+0x172/0x1b0 > warn_slowpath_fmt+0xb4/0xf0 > ? __warn+0x1b0/0x1b0 > ? debug_check_no_locks_freed+0x2c0/0x2c0 > ? cpudl_set+0x3d/0x2b0 > replenish_dl_entity+0x71e/0xc40 > enqueue_task_dl+0x2ea/0x12e0 > ? dl_task_timer+0x777/0x990 > ? __hrtimer_run_queues+0x270/0xa50 > dl_task_timer+0x316/0x990 > ? enqueue_task_dl+0x12e0/0x12e0 > ? enqueue_task_dl+0x12e0/0x12e0 > __hrtimer_run_queues+0x270/0xa50 > ? hrtimer_cancel+0x20/0x20 > ? hrtimer_interrupt+0x119/0x600 > hrtimer_interrupt+0x19c/0x600 > ? trace_hardirqs_off+0xd/0x10 > local_apic_timer_interrupt+0x74/0xe0 > smp_apic_timer_interrupt+0x76/0xa0 > apic_timer_interrupt+0x93/0xa0 > > The DL task will be migrated to a suitable later deadline rq once the DL > timer fires and currnet rq is offline. The rq clock of the new rq should > be updated. This patch fixes it by updating the rq clock after holding > the new rq's rq lock. > > Cc: Juri Lelli > Cc: Peter Zijlstra > Cc: Ingo Molnar > Cc: Thomas Gleixner > Cc: Matt Fleming > Signed-off-by: Wanpeng Li > --- > kernel/sched/deadline.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c > index 99b2c33..c6db3fd 100644 > --- a/kernel/sched/deadline.c > +++ b/kernel/sched/deadline.c > @@ -638,6 +638,7 @@ static enum hrtimer_restart dl_task_timer(struct hrtimer > *timer) > lockdep_unpin_lock(&rq->lock, rf.cookie); > rq = dl_task_offline_migration(rq, p); > rf.cookie = lockdep_pin_lock(&rq->lock); > + update_rq_clock(rq); > > /* > * Now that the task has been migrated to the new RQ and we > -- > 2.7.4 >
Re: [RFC PATCH] mm, hotplug: get rid of auto_online_blocks
On Tue 14-03-17 14:20:14, Igor Mammedov wrote: > On Mon, 13 Mar 2017 13:28:25 +0100 > Michal Hocko wrote: > > > On Mon 13-03-17 11:55:54, Igor Mammedov wrote: > > > On Thu, 9 Mar 2017 13:54:00 +0100 > > > Michal Hocko wrote: [...] > > > > The kernel is supposed to provide a proper API and that is sysfs > > > > currently. I am not entirely happy about it either but pulling a lot of > > > > code into the kernel is not the rigth thing to do. Especially when > > > > different usecases require different treatment. > > > > > > If it could be done from kernel side alone, it looks like a better way > > > to me not to involve userspace at all. And for ACPI based x86/ARM it's > > > possible to implement without adding a lot of kernel code. > > > > But this is not how we do the kernel development. We provide the API so > > that userspace can implement the appropriate policy on top. We do not > > add random knobs to implement the same thing in the kernel. Different > > users might want to implement different onlining strategies and that is > > hardly describable by a single global knob. Just look at the s390 > > example provided earlier. Please try to think out of your usecase scope. > > And could you think outside of legacy sysfs based onlining usecase scope? Well, I always prefer a more generic solution which supports more usecases and I am trying really hard to understand usecases you are coming up with. So far I have heard that the current sysfs behavior is broken (which is true!) and some very vague arguments about why we need to online as quickly as possible to the point that userspace handling is an absolute no go. To be honest I still consider the later a non-issue. If the only thing you care about is the memory footprint of the first phase then I believe this is fixable. Memblock and section descriptors should be the only necessary thing to allocate and that is not much. As an aside, the more I think about the way the original authors separated the physical hotadd from onlining the more I appreciate that decision because the way how the memory can be online is definitely not carved in stone and evolves with usecases. I believe nobody expected that memory could be onlined as movable back then and I am pretty sure new ways will emerge over time. > I don't think that S390 comparing with x86 is correct as platforms > and hardware implementations of memory hotplug are different with > correspondingly different requirements, hence > CONFIG_MEMORY_HOTPLUG_DEFAULT_ONLINE > were introduced to allows platform specify behavior. There are different usecases which are arch agnostic. E.g. decide the movability based on some criterion (e.g. specific node, physical address range and what not). Global auto onlining cannot handle those for obvious reasons and a config option will not do achieve that for the same reason. > For x86/ARM(+ACPI) it's possible to implement hotplug in race free > way inside kernel without userspace intervention, onlining memory > using hardware vendor defined policy (ACPI SRAT/Memory device describe > memory sufficiently to do it) so user won't have to do it manually, > config option is a convenient way to enable new feature for platforms > that could support it. Sigh. Can you see the actual difference between the global kernel policy and the policy coming from the specific hardware (ACPI etc...)? I am not opposing auto onlining based on the ACPI attributes. But what we have now is a policy _in_the_kernel_. This is almost always a bad idea and I do not see any strong argument why it would be any different in this particular case. Actually your current default in Fedora makes it harder for anybody to use movable zones/nodes. > It's good to maintain uniform API to userspace as far as API does > the job, but being stuck to legacy way isn't good when > there is a way (even though it's limited to limited set of platforms) > to improve it by removing need for API, making overall less complex > and race-less (more reliable) system. then convince your virtualization platform to provide necessary data for the memory auto onlining via ACPI etc... > > > That's one more of a reason to keep CONFIG_MEMORY_HOTPLUG_DEFAULT_ONLINE > > > so we could continue on improving kernel only auto-onlining > > > and fixing current memory hot(un)plug issues without affecting > > > other platforms/users that are no interested in it. > > > > I really do not see any reason to keep the config option. Setting up > > this to enabled is _wrong_ thing to do in general purpose > > (distribution) kernel and a kernel for the specific usecase can achieve > > the same thing via boot command line. > > I have to disagree with you that setting policy 'not online by default' > in kernel is more valid than opposite policy 'online by default'. > It maybe works for your usecases but it doesn't mean that it suits > needs of others. Well, as described above there are good reasons to not hardwire any policy into the kernel beca
Re: [PATCH] [media] v4l2-dv-timings: Introduce v4l2_calc_fps()
On 03/14/2017 08:14 PM, Jose Abreu wrote: > Hi Hans, > > > On 14-03-2017 07:24, Hans Verkuil wrote: >>> Right, I was forgetting about this ... >>> >>> So: >>> 1) Most of HDMI receivers do not have the expected precision in >>> measuring pixel clock value; >> s/Most/Some/ >> >> Newer HDMI receivers tend to have better precision. >> >> However, the 1000/1001 factor is within the error of margin that the HDMI >> spec has for the pixelclock, so even if it is 59.94 you still (theoretically) >> do not know if that is because it really has that fps or if the source just >> has >> a bad clock. > > Hmm. But if source has a bad clock then it won't send at the > expected frame rate, so if we are able to measure pixel clock > value we will get the approximated frame rate for that source, > right? Unless the source also doesn't have standard h/v timings, > but as long as receiver detects this correctly then we can calculate. s/bad clock/slightly different clock/ The problem is that the HDMI spec has an error of margin for the pixelclock of (I think) 0.25%. The difference in pixelclock between 60 and 59.94 Hz is about 0.1%. In addition the source clock and the sink clock will run at slightly different speeds. So all this makes it hard to reliably measure. Now, we never tested this and in reality the difference between 60 an 59.94 might be as clear as day and night (for receivers with sufficient timer resolution). So that's why more information is needed. > >> >> It's a bit theoretical, in practice you can assume the source really is >> sending >> at 59.94 AFAIK. >> >>> 2) Most (I would guess all of them?) have access to AVI infoframe >>> contents; >> All will have that. >> >>> 3) The FPS value is generally used by applications to calculate >>> expected frame rate and number of frames dropped (right?); >> Not really. Most HDMI drivers do not implement g_parm, instead they fill in >> the detected pixelclock in QUERY_DV_TIMINGS, leaving it up to the application >> to calculate the fps from that. >> >>> 4) The factor in FPS value can be adjusted by 1000/1001; >>> >>> From these points I would propose in just using the vic and drop >>> the resolution in fps a little bit, do you agree? >> The reality is that how to detect the 1000/1001 reduced fps is fuzzy. Part of >> the reason for that is that most of the HDMI receivers we have in the kernel >> were developed by Cisco/Tandberg (i.e. mostly me) for our video conferencing >> systems, and those all run at 60 Hz. So we never had the need to detect >> 59.94 vs >> 60 Hz. In addition, some of the older Analog Devices devices didn't have the >> resolution to detect the difference. >> >> So I always held off a bit with defining exactly how to do this since I had >> no experience with it. >> >> My question to you is: can you reliably detect the difference between 60 and >> 59.94 >> Hz and between 24 and 23.976 Hz by just the measured pixelclock? >> >> You need to test this with different sources, not just signal generators. You >> probably get a range of pixelclock values for the same framerate for >> different >> sources, since each source has their own clock. > > I will have to conduct more tests to confirm but the expected > resolution is more than enough to detect 1000/1001 changes. > >> >> My preference would be to extend query_dv_timings a bit for this: >> >> >> Add a flag V4L2_DV_FL_CAN_DETECT_REDUCED_FPS. If set, then the hw can detect >> the >> difference between regular fps and 1000/1001 fps. Note: this is only valid >> for >> timings of VIC codes with the V4L2_DV_FL_CAN_REDUCE_FPS flag set. > > Where should we set the flag? In v4l2_dv_timings_cap? I was thinking v4l2_bt_timings, but a capability in v4l2_bt_timings_cap is not a bad idea. Although that's global while having it in v4l2_bt_timings makes it specific to the detected timings. Just in case the hardware can detect it for some pixelclock frequencies, but not for others. But I'm not sure if that can happen. > >> >> Allow V4L2_DV_FL_REDUCED_FPS to be used for receivers if >> V4L2_DV_FL_CAN_DETECT_REDUCED_FPS >> is set. >> >> For standard VIC codes the pixelclock returned by query_dv_timings is that >> of the >> corresponding VIC timing, not what is measured. This will ensure fixed fps >> values >> >> g_parm should calculate the fps based on the v4l2_bt_timings struct, looking >> at the >> REDUCES_FPS flags. >> >> For those receivers that cannot detect the difference, the fps will be >> 24/30/60 Hz, >> for those that can detect the difference g_parm can check if both >> V4L2_DV_FL_CAN_DETECT_REDUCED_FPS >> and V4L2_DV_FL_REDUCED_FPS are set and reduce the fps by 1000/1001. >> >> >> If your hw can reliably detect the difference, then now is a good time to >> close >> this gap in the DV_TIMINGS API. > > Sounds nice :) Let me conduct more tests first and I will try to > make the patch. Nice! Regards, Hans > > Best regards, > Jose Miguel Abreu > >> >> Regards, >> >> Hans
Re: [PATCH] mtd: nand: use .read_oob() instead of .cmdfunc() for bad block check
On Wed, 15 Mar 2017 09:55:13 +0900
Masahiro Yamada wrote:
> Hi Boris,
>
> Thanks for your review.
>
> 2017-03-15 5:58 GMT+09:00 Boris Brezillon
> :
> > On Wed, 15 Mar 2017 02:45:48 +0900
> > Masahiro Yamada wrote:
> >
> >> The nand_default_block_markbad() is the default implementation of
> >> chip->block_markbad(). This is called for marking a block as bad.
> >> It invokes nand_do_write_oob(), then calls a higher level accessor
> >> ecc->write_oob().
> >>
> >> On the other hand, when reading BBM from the OOB, chip->block_bad()
> >> is called, and nand_block_bad() is the default implementation. This
> >> function calls a lower level chip->cmdfunc(). If a driver wants to
> >> re-use nand_block_bad(), it is required to support NAND_CMD_READOOB
> >> in its cmdfunc().
> >
> > This is part of the basic/mandatory operations that should be supported
> > by all drivers.
>
>
> My main motivation of this patch is to save NAND_CMD_READOOB
> implemenation in cmdfunc().
>
>
> Please look at line 1292 of drivers/mtd/nand/denali.c
>
> case NAND_CMD_READOOB:
> /* TODO: Read OOB data */
> break;
>
Yes, I know, and unfortunately that's not the only driver to partially
implement the set of operation the core assume to be always supported.
>
> Currently, this driver can not check BBM at all.
>
>
> If all drivers should support NAND_CMD_READOOB
> regardless of this patch, my main motivation of this patch will be lost.
Well, I see another reason to move to the ecc->read_oob() approach:
some NAND controllers are protecting the BBM with ECC, if you just use
->cmdfunc(READOOB) + ->read_buf() you don't get this ECC protection.
>
>
> >> This is strange. If the controller supports
> >> optimized read operation and the driver has its own ecc->read_oob(),
> >> it should be able to use it.
> >
> > I agree with this one. I guess the idea behind this default
> > implementation was to avoid reading the whole OOB area, or maybe this
> > function was implemented before we had ECC support. Anyway, the
> > overhead should be negligible with your approach.
> >
> >> Besides, NAND_CMD_READOOB (0x50) is
> >> not a real command for large page devices. So, recent drivers may
> >> not be happy to handle this command.
> >
> > Well, that's the whole problem with the ->cmdfunc() hook, even if it's
> > passed raw NAND command identifiers, these are actually encoding NAND
> > operations, and not necessarily the exact command that should be sent to
> > the NAND.
>
>
> I was misunderstanding this.
>
> If operations are hooked by higher level accessors
> and some low-level commands never get chance to be executed,
> I thought I need not implement them.
That's true for some of them (for example ->onfi_set/get_features()),
but there's no clear rule saying which commands have to be supported in
->cmdfunc() and which one can be implemented as high-level hooks.
Most of the time, I recommend to implement ->cmd_ctrl() and rely on the
default ->cmdfunc() implementation, so that, each time a new feature
(support for a new NAND operation) is added to the core your driver will
support it natively.
I know some controllers are not fitting so well in this model, but most
of them do.
>
> > See what's done in nand_command_lp(), and how some commands are
> > actually generating a sequence of 2 commands [1], or how
> > NAND_CMD_READOOB is transformed into NAND_CMD_READ0 [2].
>
> So, what should I do for denali.c?
>
> Maybe, copy the most logic of nand_command_lp() into denali_cmdfunc()?
Ideally, get rid of denali_cmdfunc() and implement denali_cmd_ctrl(),
but I'm not sure how feasible this is.
>
>
>
> >> if (chip->bbt_options & NAND_BBT_SCANLASTPAGE)
> >> ofs += mtd->erasesize - mtd->writesize;
> >> @@ -364,30 +364,26 @@ static int nand_block_bad(struct mtd_info *mtd,
> >> loff_t ofs)
> >> page = (int)(ofs >> chip->page_shift) & chip->pagemask;
> >>
> >> do {
> >> - if (chip->options & NAND_BUSWIDTH_16) {
> >> - chip->cmdfunc(mtd, NAND_CMD_READOOB,
> >> - chip->badblockpos & 0xFE, page);
> >> - bad = cpu_to_le16(chip->read_word(mtd));
> >> - if (chip->badblockpos & 0x1)
> >> - bad >>= 8;
> >> + res = chip->ecc.read_oob(mtd, chip, page);
> >> + if (!res) {
> >> + bad = chip->oob_poi[chip->badblockpos];
> >
> > Hm, even if the current code is only testing one byte, I wonder
> > if we shouldn't test the 2 bytes here when we're dealing with 16bits
> > NANDs.
>
>
>
> I was not quite sure about this, so I tried my best
> to keep the current behavior.
I'll check in the ONFI spec.
>
>
>
> >>
> >> - if (likely(chip->badblockbits == 8))
> >> - res = bad != 0xFF;
> >> - else
> >> - res = hweight8(bad) < chip-
Re: WTH is going on with memory hotplug sysf interface (was: Re: [RFC PATCH] mm, hotplug: get rid of auto_online_blocks)
On Tue 14-03-17 20:35:21, Andrea Arcangeli wrote:
> Hello,
>
> On Mon, Mar 13, 2017 at 10:21:45AM +0100, Michal Hocko wrote:
> > On Fri 10-03-17 13:00:37, Reza Arbab wrote:
> > > On Fri, Mar 10, 2017 at 04:53:33PM +0100, Michal Hocko wrote:
> > > >OK, so while I was playing with this setup some more I probably got why
> > > >this is done this way. All new memblocks are added to the zone Normal
> > > >where they are accounted as spanned but not present.
> > >
> > > It's not always zone Normal. See zone_for_memory(). This leads to a
> > > workaround for having to do online_movable in descending block order.
> > > Instead of this:
> > >
> > > 1. probe block 34, probe block 33, probe block 32, ...
> > > 2. online_movable 34, online_movable 33, online_movable 32, ...
> > >
> > > you can online_movable the first block before adding the rest:
> >
> > I do I enforce that behavior when the probe happens automagically?
>
> What I provided as guide to online as movable in current and older
> kernels is:
>
> 1) Remove udev rule
> 2) After adding memory with qemu/libvirt API run in the guest
>
> --- workaround start
> #!/bin/bash
> for i in `ls -d1 /sys/devices/system/memory/memory* | sort -nr -t y -k 5`; do
> if [ "`cat $i/state`" == "offline" ]; then echo online_movable > $i/state ;
> fi; done
> --- workaround end
>
> That's how bad is onlining as movable for memory hotunplug.
Yeah, this is really yucky. Fortunately, I already have a working prototype
which removes this restriction altogether.
> > > 1. probe block 32, online_movable 32
> > > 2. probe block 33, probe block 34, ...
> > > - zone_for_memory() will cause these to start Movable
> > > 3. online 33, online 34, ...
> > > - they're already in Movable, so online_movable is equivalentr
> > >
> > > I agree with your general sentiment that this stuff is very nonintuitive.
> >
> > My criterion for nonintuitive is probably different because I would call
> > this _completely_unusable_. Sorry for being so loud about this but the
> > more I look into this area the more WTF code I see. This has seen close
> > to zero review and seems to be building up more single usecase code on
> > top of previous. We need to change this, seriously!
>
> It's not a bug, but when I found it I called it a "constraint" and
> when I debugged it (IIRC) it originated here:
>
> } else if (online_type == MMOP_ONLINE_MOVABLE) {
> if (!zone_can_shift(pfn, nr_pages, ZONE_MOVABLE, &zone_shift))
> return -EINVAL;
> }
>
> Fixing it so you could online as movable even if it wasn't the last
> block was in my todo list but then we had other plans.
>
> Unfortunately unless pfn+nr_pages of the newly created Movable zone
> matches the end of the normal zone (or whatever was there that has to
> be converted to Movable), it will fail onlining as movable.
Well, I think the main problem is that we associate pages added in the
first phase (probe) to the Normal zone. The everything else is just a
fallout and fiddling to make it work somehow.
[...]
> To be clear, I'm not necessarily against eventually removing
> _DEFFAULT_ONLINE, but an equally reliable and comparably fast
> alternative should be provided first and there's no such alternative
> right now.
As pointed in other reply that is not an intention here. I primarily
wanted to understand the scope of the problem. I believe this config
option was rushed into the kernel without considering other alternatives
which would make the hotplug more usable by others as well.
> If s390 has special issues requiring admin or a software hotplug
> manager app to enable blocks of memory by hand, the _DEFFAULT_ONLINE
> could be then an option selected or not selected by
> arch/*/Kconfig. The udev rule is still an automatic action so it's 1:1
> with the in-kernel feature. If the in-kernel automatic onlining is not
> workable on s390 I would assume the udev rule is also not workable.
But this is not about s390. It is about different usecases which require
different onlining policy and that is the main problem of the hardcoded
one in the kernel. See the other reply.
--
Michal Hocko
SUSE Labs
Re: [PATCH 4/4] eeprom: at24: Add OF device ID table
> So there isn't an agreement if is better to just rely in the current behavior > (and have a superfluous I2C device ID table) or fix the I2C core (and need a > OF device ID table). For at24, the i2c_device_id table is not superfluous! It is used outside the DT world as well. > Indeed, but these all are compatible strings used by DTS in mainline and so > should be in the OF device ID table in order to be matched and the proper > modalias reported (once the I2C core is fixed). I'd think we should fix the DTS files instead to contain a fallback we agree on. Say, we agree on "atmel,at24c01" as a the generic fallback, the DTS should contain: compatible = ",", "atmel,at24c01" And we shall only keep compatible values in the source file which differ in behaviour fromt the generic case. > One option is to add #ifdef CONFIG_OF guards for the OF device table > definition > but again there's no agreement on that one since some maintainers say the it > is > better to always build the OF ID table than having #ifdefery in C code... I don't like the #ifdeffery as well. signature.asc Description: PGP signature
Re: [PATCH v6 0/4] Broadcom SBA RAID support
On Tue, Mar 14, 2017 at 10:26 PM, Dan Williams wrote: > On Mon, Mar 6, 2017 at 1:43 AM, Anup Patel wrote: >> The Broadcom SBA RAID is a stream-based device which provides >> RAID5/6 offload. >> >> It requires a SoC specific ring manager (such as Broadcom FlexRM >> ring manager) to provide ring-based programming interface. Due to >> this, the Broadcom SBA RAID driver (mailbox client) implements >> DMA device having one DMA channel using a set of mailbox channels >> provided by Broadcom SoC specific ring manager driver (mailbox >> controller). >> >> The Broadcom SBA RAID hardware requires PQ disk position instead >> of PQ disk coefficient. To address this, we have added raid_gflog >> table which will help driver to convert PQ disk coefficient to PQ >> disk position. >> >> This patchset is based on Linux-4.11-rc1 and depends on patchset >> "[PATCH v5 0/2] Broadcom FlexRM ring manager support" >> >> It is also available at sba-raid-v6 branch of >> https://github.com/Broadcom/arm64-linux.git >> > [..] >> >> Anup Patel (4): >> lib/raid6: Add log-of-2 table for RAID6 HW requiring disk position >> async_tx: Fix DMA_PREP_FENCE usage in do_async_gen_syndrome() >> dmaengine: Add Broadcom SBA RAID driver >> dt-bindings: Add DT bindings document for Broadcom SBA RAID driver > > For the dmaengine and async_tx changes: > > Acked-by: Dan Williams > Thanks Dan ... Regards, Anup
Re: [PATCH v6 0/4] Broadcom SBA RAID support
On Wed, Mar 15, 2017 at 12:18 AM, Shaohua Li wrote: > On Tue, Mar 14, 2017 at 09:56:35AM -0700, Dan Williams wrote: >> On Mon, Mar 6, 2017 at 1:43 AM, Anup Patel wrote: >> > The Broadcom SBA RAID is a stream-based device which provides >> > RAID5/6 offload. >> > >> > It requires a SoC specific ring manager (such as Broadcom FlexRM >> > ring manager) to provide ring-based programming interface. Due to >> > this, the Broadcom SBA RAID driver (mailbox client) implements >> > DMA device having one DMA channel using a set of mailbox channels >> > provided by Broadcom SoC specific ring manager driver (mailbox >> > controller). >> > >> > The Broadcom SBA RAID hardware requires PQ disk position instead >> > of PQ disk coefficient. To address this, we have added raid_gflog >> > table which will help driver to convert PQ disk coefficient to PQ >> > disk position. >> > >> > This patchset is based on Linux-4.11-rc1 and depends on patchset >> > "[PATCH v5 0/2] Broadcom FlexRM ring manager support" >> > >> > It is also available at sba-raid-v6 branch of >> > https://github.com/Broadcom/arm64-linux.git >> > >> [..] >> > >> > Anup Patel (4): >> > lib/raid6: Add log-of-2 table for RAID6 HW requiring disk position >> > async_tx: Fix DMA_PREP_FENCE usage in do_async_gen_syndrome() >> > dmaengine: Add Broadcom SBA RAID driver >> > dt-bindings: Add DT bindings document for Broadcom SBA RAID driver >> >> For the dmaengine and async_tx changes: >> >> Acked-by: Dan Williams >> >> The raid change should get an ack from Shaohua. > > For the raid6 part: > > Acked-by: Shaohua Li Thanks Shaohua ... Regards, Anup
Re: [PATCH v2 16/23] MAINTAINERS: Add file patterns for powerpc device tree bindings
Hi Michael,
On Wed, Mar 15, 2017 at 1:19 AM, Michael Ellerman wrote:
> Geert Uytterhoeven writes:
>> Submitters of device tree binding documentation may forget to CC
>> the subsystem maintainer if this is missing.
>>
>> Signed-off-by: Geert Uytterhoeven
>> Cc: Benjamin Herrenschmidt
>> Cc: Paul Mackerras
>> Cc: Michael Ellerman
>> Cc: linuxppc-...@lists.ozlabs.org
>> ---
>> Please apply this patch directly if you want to be involved in device
>> tree binding documentation for your subsystem.
>>
>> v2:
>> - Rebased on top of commit a42715830d552d7c ("MAINTAINERS: Remove
>> powerpc's "opal" pattern match), which just added "powerpc/opal",
>> while obviously the whole "powerpc" hierarchy is of interest.
>>
>> Impact on next-20170310:
>
> Actual diff ignoring ordering etc:
>
> +Benjamin Herrenschmidt (supporter:LINUX FOR
> POWERPC (32-BIT AND 64-BIT))
> +Paul Mackerras (supporter:LINUX FOR POWERPC (32-BIT AND
> 64-BIT))
> +linuxppc-...@lists.ozlabs.org (open list:LINUX FOR POWERPC (32-BIT AND
> 64-BIT))
> -Scott Wood (commit_signer:5/11=45%)
> -Zhao Qiang (commit_signer:4/11=36%,authored:4/11=36%)
> -Christian Lamparter (commit_signer:1/11=9%)
> -yangbo lu (authored:1/11=9%)
> -"Otto Kekäläinen" (authored:1/11=9%)
> -Chris Packham (authored:1/11=9%)
> -York Sun (authored:1/11=9%)
>
> Which looks bad as all the NXP folks get dropped, but they should be
> reading linuxppc-dev. So I think I'll merge this, unless anyone
> disagrees.
They got dropped because in the absence of a maintainer entry, the
last committers are listed. If they need to be listed, I can send patches to add
more specific entries for 4xx and fsl DT bindings, like:
diff --git a/MAINTAINERS b/MAINTAINERS
index 0f1c2f96c99aa936..40b392a4f399adbe 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5266,6 +5266,7 @@ M:Scott Wood
L: linuxppc-...@lists.ozlabs.org
L: linux-arm-ker...@lists.infradead.org
S: Maintained
+F: Documentation/devicetree/bindings/powerpc/fsl/
F: drivers/soc/fsl/
F: include/linux/fsl/
@@ -7540,6 +7541,7 @@ M:Matt Porter
W: http://www.penguinppc.org/
L: linuxppc-...@lists.ozlabs.org
S: Maintained
+F: Documentation/devicetree/bindings/powerpc/4xx/
F: arch/powerpc/platforms/40x/
F: arch/powerpc/platforms/44x/
OK?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [RESEND PATCH v3 2/2] phy: Group vendor specific phy drivers
Am Dienstag, 14. März 2017, 11:52:50 CET schrieb Vivek Gautam: > Adding vendor specific directories in phy to group > phy drivers under their respective vendor umbrella. > > Also updated the MAINTAINERS file to reflect the correct > directory structure for phy drivers. > > Signed-off-by: Vivek Gautam > Acked-by: Heiko Stuebner > Acked-by: Viresh Kumar > Cc: Kishon Vijay Abraham I > Cc: David S. Miller > Cc: Geert Uytterhoeven > Cc: Yoshihiro Shimoda > Cc: Guenter Roeck > Cc: Heiko Stuebner > Cc: Viresh Kumar > Cc: Maxime Ripard > Cc: Chen-Yu Tsai > Cc: Sylwester Nawrocki > Cc: Krzysztof Kozlowski > Cc: Jaehoon Chung > Cc: linux-arm-ker...@lists.infradead.org > Cc: linux-arm-...@vger.kernel.org > Cc: linux-kernel@vger.kernel.org > Cc: linux-o...@vger.kernel.org > Cc: linux-renesas-...@vger.kernel.org > Cc: linux-rockc...@lists.infradead.org > Cc: linux-samsung-...@vger.kernel.org > Cc: linux-...@vger.kernel.org > --- > > Corrected Krzysztof's email-id. Added linux-arm-msm. > > Hi Heiko, Viresh, > It's been a year since the last version of this patch was posted. > Kishon has agreed to pull this change now. I am carrying forward > your Acks since there are no functional changes. > I have taken care of the drivers that were added/removed since > the last version. > Please feel free to jump in if you have any concerns. still looks all good and I gave that a try on 4.11-rc2 yesterday as well. Heiko
[v2 PATCH] powernv-cpuidle: Validate DT property array size
From: "Gautham R. Shenoy"
The various properties associated with powernv idle states such as
names, flags, residency-ns, latencies-ns, psscr, psscr-mask are
exposed in the device-tree as property arrays such the pointwise
entries in each of these arrays correspond to the properties of the
same idle state.
This patch validates that the lengths of the property arrays are the
same. If there is a mismatch, the patch will ensure that we bail out
and not expose the platform idle states via cpuidle.
Signed-off-by: Gautham R. Shenoy
---
v1: https://lkml.org/lkml/2017/2/23/349
Changes from v1: Print the full property array name in warning message.
drivers/cpuidle/cpuidle-powernv.c | 64 +--
1 file changed, 61 insertions(+), 3 deletions(-)
diff --git a/drivers/cpuidle/cpuidle-powernv.c
b/drivers/cpuidle/cpuidle-powernv.c
index 3705930..a06df51 100644
--- a/drivers/cpuidle/cpuidle-powernv.c
+++ b/drivers/cpuidle/cpuidle-powernv.c
@@ -197,11 +197,25 @@ static inline void add_powernv_state(int index, const
char *name,
stop_psscr_table[index].mask = psscr_mask;
}
+/*
+ * Returns 0 if prop1_len == prop2_len. Else returns -1
+ */
+static inline int validate_dt_prop_sizes(const char *prop1, int prop1_len,
+const char *prop2, int prop2_len)
+{
+ if (prop1_len == prop2_len)
+ return 0;
+
+ pr_warn("cpuidle-powernv: array sizes don't match for %s and %s\n",
+ prop1, prop2);
+ return -1;
+}
+
static int powernv_add_idle_states(void)
{
struct device_node *power_mgt;
int nr_idle_states = 1; /* Snooze */
- int dt_idle_states;
+ int dt_idle_states, count;
u32 latency_ns[CPUIDLE_STATE_MAX];
u32 residency_ns[CPUIDLE_STATE_MAX];
u32 flags[CPUIDLE_STATE_MAX];
@@ -226,6 +240,21 @@ static int powernv_add_idle_states(void)
goto out;
}
+ count = of_property_count_u32_elems(power_mgt,
+ "ibm,cpu-idle-state-latencies-ns");
+
+ if (validate_dt_prop_sizes("ibm,cpu-idle-state-flags", dt_idle_states,
+ "ibm,cpu-idle-state-latencies-ns",
+ count) != 0)
+ goto out;
+
+ count = of_property_count_strings(power_mgt,
+ "ibm,cpu-idle-state-names");
+ if (validate_dt_prop_sizes("ibm,cpu-idle-state-flags", dt_idle_states,
+ "ibm,cpu-idle-state-names",
+ count) != 0)
+ goto out;
+
/*
* Since snooze is used as first idle state, max idle states allowed is
* CPUIDLE_STATE_MAX -1
@@ -260,6 +289,22 @@ static int powernv_add_idle_states(void)
has_stop_states = (flags[0] &
(OPAL_PM_STOP_INST_FAST | OPAL_PM_STOP_INST_DEEP));
if (has_stop_states) {
+ count = of_property_count_u64_elems(power_mgt,
+ "ibm,cpu-idle-state-psscr");
+ if (validate_dt_prop_sizes("ibm,cpu-idle-state-flags",
+ dt_idle_states,
+ "ibm,cpu-idle-state-psscr",
+ count) != 0)
+ goto out;
+
+ count = of_property_count_u64_elems(power_mgt,
+
"ibm,cpu-idle-state-psscr-mask");
+ if (validate_dt_prop_sizes("ibm,cpu-idle-state-flags",
+ dt_idle_states,
+ "ibm,cpu-idle-state-psscr-mask",
+ count) != 0)
+ goto out;
+
if (of_property_read_u64_array(power_mgt,
"ibm,cpu-idle-state-psscr", psscr_val, dt_idle_states)) {
pr_warn("cpuidle-powernv: missing
ibm,cpu-idle-state-psscr in DT\n");
@@ -274,8 +319,21 @@ static int powernv_add_idle_states(void)
}
}
- rc = of_property_read_u32_array(power_mgt,
- "ibm,cpu-idle-state-residency-ns", residency_ns,
dt_idle_states);
+ count = of_property_count_u32_elems(power_mgt,
+ "ibm,cpu-idle-state-residency-ns");
+
+ if (count < 0) {
+ rc = count;
+ } else if (validate_dt_prop_sizes("ibm,cpu-idle-state-flags",
+ dt_idle_states,
+ "ibm,cpu-idle-state-residency-ns",
+ count) != 0) {
+ goto out;
+ } else {
+ rc = of_property_read_u32_array(power_mgt,
+
"ibm,cpu-idle-state-residency-ns",
+
Re: [PATCH v3 0/7] mmc: bcm2835: Add new driver for the sdhost controller
Hi, > First the flipping of the mmc host driver for the SD card slot will > cause issues for users that build it as a module. When I tested this > on Fedora the first update I ended up with a system that didn't boot. Yep, switching drivers is a pain point here indeed. Possibly we could fix that by adding a MODULE_SOFTDEP() to the iproc driver? Comments? Better ideas? > Also i often see the device hang for a long period when systemd probes > for rfkill status, sometimes it needs to be reset but it generally > gets there. What device is that? rpi3 with wifi? > [6.529079] Hardware name: Generic DT based system > [6.529106] [] (unwind_backtrace) from [] > (show_stack+0x18/0x1c) > [6.529122] [] (show_stack) from [] > (dump_stack+0x80/0xa0) > [6.529137] [] (dump_stack) from [] (__warn+0xe4/0x104) > [6.529150] [] (__warn) from [] > (warn_slowpath_fmt+0x3c/0x4c) > [6.529166] [] (warn_slowpath_fmt) from [] > (check_flush_dependency+0xac/0x134) > [6.529184] [] (check_flush_dependency) from [] > (flush_work+0xa0/0x178) > [6.529201] [] (flush_work) from [] > (drain_all_pages+0x1a8/0x1cc) > [6.529221] [] (drain_all_pages) from [] > (start_isolate_page_range+0x168/0x1b4) > [6.529239] [] (start_isolate_page_range) from > [] (alloc_contig_range+0xd4/0x314) > [6.529258] [] (alloc_contig_range) from [] > (cma_alloc+0x188/0x300) > [6.529275] [] (cma_alloc) from [] > (__alloc_from_contiguous+0x40/0xd8) > [6.529290] [] (__alloc_from_contiguous) from > [] (cma_allocator_alloc+0x3c/0x44) > [6.529303] [] (cma_allocator_alloc) from [] > (__dma_alloc+0x1d4/0x2f0) > [6.529317] [] (__dma_alloc) from [] > (arm_dma_alloc+0x3c/0x48) > [6.529331] [] (arm_dma_alloc) from [] > (dma_pool_alloc+0x124/0x240) > [6.529356] [] (dma_pool_alloc) from [] > (bcm2835_dma_create_cb_chain+0xb0/0x1dc [bcm2835_dma]) > [6.529385] [] (bcm2835_dma_create_cb_chain > [bcm2835_dma]) from [] (bcm2835_dma_prep_slave_sg+0xf0/0x25c > [bcm2835_dma]) > [6.529418] [] (bcm2835_dma_prep_slave_sg [bcm2835_dma]) > from [] (bcm2835_request+0x2a4/0x3f4 [bcm2835]) > [6.529548] [] (bcm2835_request [bcm2835]) from > [] (mmc_start_request+0x1f8/0x264 [mmc_core]) > [6.529756] [] (mmc_start_request [mmc_core]) from > [] (mmc_start_areq+0x2c8/0x318 [mmc_core]) > [6.529890] [] (mmc_start_areq [mmc_core]) from > [] (mmc_blk_issue_rw_rq+0xc0/0x308 [mmc_block]) > [6.529943] [] (mmc_blk_issue_rw_rq [mmc_block]) from > [] (mmc_blk_issue_rq+0x418/0x428 [mmc_block]) > [6.529997] [] (mmc_blk_issue_rq [mmc_block]) from > [] (mmc_queue_thread+0x148/0x1bc [mmc_block]) > [6.530031] [] (mmc_queue_thread [mmc_block]) from > [] (kthread+0x120/0x138) > [6.530049] [] (kthread) from [] > (ret_from_fork+0x14/0x3c) > [6.530055] ---[ end trace 221a5a14ca55fa22 ]--- > [6.545765] mmcblk0: p1 p2 p3 p4 > [6.566015] random: fast init done > [6.623699] mmc1: new high speed SDIO card at address 0001 Looks more like a cma allocator issue on a quick glance. cheers, Gerd
RE: [PATCH 4/4] drm/amdgpu: resize VRAM BAR for CPU access
Does that means we don't need invisible vram later?
David
-Original Message-
From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
Christian K?nig
Sent: Wednesday, March 15, 2017 3:38 PM
To: Ayyappa Ch
Cc: linux-...@vger.kernel.org; linux-kernel@vger.kernel.org;
amd-...@lists.freedesktop.org; platform-driver-...@vger.kernel.org;
helg...@kernel.org; dri-de...@lists.freedesktop.org
Subject: Re: [PATCH 4/4] drm/amdgpu: resize VRAM BAR for CPU access
Carizzo is an APU and resizing BARs isn't needed nor supported there.
The CPU can access the full stolen VRAM directly on that hardware.
As far as I know ASICs with support for this are Tonga, Fiji and all Polaris
variants.
Christian.
Am 15.03.2017 um 08:23 schrieb Ayyappa Ch:
> Is it possible on Carrizo asics? Or only supports on newer asics?
>
> On Mon, Mar 13, 2017 at 6:11 PM, Christian König
> wrote:
>> From: Christian König
>>
>> Try to resize BAR0 to let CPU access all of VRAM.
>>
>> Signed-off-by: Christian König
>> ---
>> drivers/gpu/drm/amd/amdgpu/amdgpu.h| 1 +
>> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 29
>> +
>> drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c | 8 +---
>> drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c | 8 +---
>> 4 files changed, 40 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
>> index 3b81ded..905ded9 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
>> @@ -1719,6 +1719,7 @@ uint64_t amdgpu_ttm_tt_pte_flags(struct amdgpu_device
>> *adev, struct ttm_tt *ttm,
>> struct ttm_mem_reg *mem);
>> void amdgpu_vram_location(struct amdgpu_device *adev, struct amdgpu_mc
>> *mc, u64 base);
>> void amdgpu_gtt_location(struct amdgpu_device *adev, struct
>> amdgpu_mc *mc);
>> +void amdgpu_resize_bar0(struct amdgpu_device *adev);
>> void amdgpu_ttm_set_active_vram_size(struct amdgpu_device *adev, u64 size);
>> int amdgpu_ttm_init(struct amdgpu_device *adev);
>> void amdgpu_ttm_fini(struct amdgpu_device *adev); diff --git
>> a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>> index 118f4e6..92955fe 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>> @@ -692,6 +692,35 @@ void amdgpu_gtt_location(struct amdgpu_device *adev,
>> struct amdgpu_mc *mc)
>> mc->gtt_size >> 20, mc->gtt_start, mc->gtt_end);
>> }
>>
>> +/**
>> + * amdgpu_resize_bar0 - try to resize BAR0
>> + *
>> + * @adev: amdgpu_device pointer
>> + *
>> + * Try to resize BAR0 to make all VRAM CPU accessible.
>> + */
>> +void amdgpu_resize_bar0(struct amdgpu_device *adev) {
>> + u32 size = max(ilog2(adev->mc.real_vram_size - 1) + 1, 20) - 20;
>> + int r;
>> +
>> + r = pci_resize_resource(adev->pdev, 0, size);
>> +
>> + if (r == -ENOTSUPP) {
>> + /* The hardware don't support the extension. */
>> + return;
>> +
>> + } else if (r == -ENOSPC) {
>> + DRM_INFO("Not enoigh PCI address space for a large BAR.");
>> + } else if (r) {
>> + DRM_ERROR("Problem resizing BAR0 (%d).", r);
>> + }
>> +
>> + /* Reinit the doorbell mapping, it is most likely moved as well */
>> + amdgpu_doorbell_fini(adev);
>> + BUG_ON(amdgpu_doorbell_init(adev));
>> +}
>> +
>> /*
>>* GPU helpers function.
>>*/
>> diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
>> b/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
>> index dc9b6d6..36a7aa5 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
>> @@ -367,13 +367,15 @@ static int gmc_v7_0_mc_init(struct amdgpu_device *adev)
>> break;
>> }
>> adev->mc.vram_width = numchan * chansize;
>> - /* Could aper size report 0 ? */
>> - adev->mc.aper_base = pci_resource_start(adev->pdev, 0);
>> - adev->mc.aper_size = pci_resource_len(adev->pdev, 0);
>> /* size in MB on si */
>> adev->mc.mc_vram_size = RREG32(mmCONFIG_MEMSIZE) * 1024ULL *
>> 1024ULL;
>> adev->mc.real_vram_size = RREG32(mmCONFIG_MEMSIZE) * 1024ULL
>> * 1024ULL;
>>
>> + if (!(adev->flags & AMD_IS_APU))
>> + amdgpu_resize_bar0(adev);
>> + adev->mc.aper_base = pci_resource_start(adev->pdev, 0);
>> + adev->mc.aper_size = pci_resource_len(adev->pdev, 0);
>> +
>> #ifdef CONFIG_X86_64
>> if (adev->flags & AMD_IS_APU) {
>> adev->mc.aper_base =
>> ((u64)RREG32(mmMC_VM_FB_OFFSET)) << 22; diff --git
>> a/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
>> b/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
>> index c087b00..7761ad3 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
>> @@ -459,13 +459,15 @
Re: [PATCH] tpm: select CONFIG_CRYPTO
Arnd,
On Tue, Mar 14, 2017 at 10:40:24PM +0100, Arnd Bergmann wrote:
> As we need the CRYPTO_HASH_INFO implementation, we should also
> select CRYPTO itself to avoid this build warning:
>
> warning: (TCG_TPM && TRUSTED_KEYS && IMA) selects CRYPTO_HASH_INFO which has
> unmet direct dependencies (CRYPTO)
>
> Fixes: c1f92b4b04ad ("tpm: enhance TPM 2.0 PCR extend to support multiple
> banks")
> Signed-off-by: Arnd Bergmann
I've already merged this and put to my next branch.
/Jarkko
> ---
> drivers/char/tpm/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/char/tpm/Kconfig b/drivers/char/tpm/Kconfig
> index af985cca413c..d520ac51c11c 100644
> --- a/drivers/char/tpm/Kconfig
> +++ b/drivers/char/tpm/Kconfig
> @@ -6,6 +6,7 @@ menuconfig TCG_TPM
> tristate "TPM Hardware Support"
> depends on HAS_IOMEM
> select SECURITYFS
> + select CRYPTO
> select CRYPTO_HASH_INFO
> ---help---
> If you have a TPM security chip in your system, which
> --
> 2.9.0
>
Re: [PATCH v2] xfs: remove kmem_zalloc_greedy
On Wed 15-03-17 01:14:27, Luis R. Rodriguez wrote:
> On Tue, Mar 14, 2017 at 11:07:38AM -0700, Darrick J. Wong wrote:
> > On Tue, Mar 14, 2017 at 05:57:45PM +0100, Luis R. Rodriguez wrote:
> > > On Tue, Mar 07, 2017 at 04:35:28PM -0800, Darrick J. Wong wrote:
> > > > The sole remaining caller of kmem_zalloc_greedy is bulkstat, which uses
> > > > it to grab 1-4 pages for staging of inobt records. The infinite loop in
> > > > the greedy allocation function is causing hangs[1] in generic/269, so
> > > > just get rid of the greedy allocator in favor of kmem_zalloc_large.
> > > > This makes bulkstat somewhat more likely to ENOMEM if there's really no
> > > > pages to spare, but eliminates a source of hangs.
> > > >
> > > > [1]
> > > > http://lkml.kernel.org/r/20170301044634.rgidgdqqiiwsmfpj%40XZHOUW.usersys.redhat.com
> > > >
> > > > Signed-off-by: Darrick J. Wong
> > > > ---
> > > > v2: remove single-page fallback
> > > > ---
> > >
> > > Since this fixes a hang how about *at the very least* a respective Fixes
> > > tag ?
> > > This fixes an existing hang so what are the stable considerations here ? I
> > > realize the answer is not easy but figured its worth asking.
> >
> > I didn't think it was appropriate to "Fixes: 77e4635ae1917" since we're
> > not fixing _greedy so much as we are killing it. The patch fixes an
> > infinite retry hang when bulkstat tries a memory allocation that cannot
> > be satisfied; and having done that, realizes there are no remaining
> > callers of _greedy and garbage collects it. The code that was there
> > before also seems capable of sleeping forever, I think.
> >
> > So the minimally invasive fix is to apply the allocation conversion in
> > bulkstat, and if there aren't any other callers of _greedy then you can
> > get rid of it too.
>
> For the stake of stable XFS users then why not do the less invasive change
> first, Cc stable, and then move on to the less backward portable solution ?
The thing is that the permanent failures for vmalloc were so unlikely
prior to 5d17a73a2ebe ("vmalloc: back off when the current task is
killed") that this was basically a non-issue before this (4.11) merge
window.
--
Michal Hocko
SUSE Labs
Re: [...] "How does the new naming scheme look like, precisely?"
On 14.03.2017 17:16, Tom Horsley wrote: > And the consistent names change every single time some > developer decides he just has to rewrite the algorithm > to make it better, or systemd decides to engluph yet > another component and not be backward compatible, or > a kernel developer gets a new motherboard where the > scheme doesn't work and his fix has the side effect > of changing the names on thousands of existing systems, etc. > > There have been at least 3 different "immutable" name > schemes in the short time the whole concept has existed. > > I finally decided to eradicate it and go back to eth0 > and friends because it was infinitely more reliable than > having to discover yet another naming scheme in every damn > release. > > Now my only problem will be that they'll probably keep changing > the name of the kernel option to disable it :-). > This sounds quite disturbing, can someone from the systemd and kernel campus comment here, as Tom claims, whether these are the facts?
Re: [PATCH] drivers/staging/goldfish/goldfish_nand.c: Fixed Coding style Warnings.
Fix the subject. The subsystem prefix is wrong and it's too vague. Change it to: [PATCH] Staging: goldfish: use __func__ instead of embedded function names On Tue, Mar 14, 2017 at 08:53:50PM -0700, mshan wrote: > Embedded function names are less appropriate to use when > refactoring, can cause function renaming. Prefer the use > of "%s", __func__ to embedded function names > > Signed-off-by: mshan Please use your legal/formal name as if you were signing a legal document. Also change the From header on your email to match. regards, dan carpenter
Re: [PATCH] s390/decompressor: fix initrd corruption caused by bss clear
On Mon, Mar 13, 2017 at 12:14:58PM -0300, Marcelo Henrique Cerri wrote: > Reorder the operations in decompress_kernel() to ensure initrd is moved > to a safe location before the bss section is zeroed. > > During decompression bss can overlap with the initrd and this can > corrupt the initrd contents depending on the size of the compressed > kernel (which affects where the initrd is placed by the bootloader) and > the size of the bss section of the decompressor. > > Also use the correct initrd size when checking for overlaps with > parmblock. > > Fixes: 06c0dd72aea3 ([S390] fix boot failures with compressed kernels) > Cc: sta...@vger.kernel.org > Reviewed-by: Joy Latten > Reviewed-by: Vineetha HariPai > Signed-off-by: Marcelo Henrique Cerri > --- > arch/s390/boot/compressed/misc.c | 35 +++ > 1 file changed, 19 insertions(+), 16 deletions(-) Applied. Thank you!
[PATCH 3/3] drm/rockchip/dsi: correct the grf_switch_reg name
For the RK3399, the grf_switch_reg name should be RK3399_GRF_SOC_CON20,
not RK3399_GRF_SOC_CON19.
Signed-off-by: Chris Zhong
---
drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
index d8f24f2..ddd5dba 100644
--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
@@ -34,7 +34,7 @@
#define RK3288_DSI0_SEL_VOP_LITBIT(6)
#define RK3288_DSI1_SEL_VOP_LITBIT(9)
-#define RK3399_GRF_SOC_CON19 0x6250
+#define RK3399_GRF_SOC_CON20 0x6250
#define RK3399_DSI0_SEL_VOP_LITBIT(0)
#define RK3399_DSI1_SEL_VOP_LITBIT(4)
@@ -1146,7 +1146,7 @@ static struct dw_mipi_dsi_plat_data
rk3288_mipi_dsi_drv_data = {
static struct dw_mipi_dsi_plat_data rk3399_mipi_dsi_drv_data = {
.dsi0_en_bit = RK3399_DSI0_SEL_VOP_LIT,
.dsi1_en_bit = RK3399_DSI1_SEL_VOP_LIT,
- .grf_switch_reg = RK3399_GRF_SOC_CON19,
+ .grf_switch_reg = RK3399_GRF_SOC_CON20,
.grf_dsi0_mode = RK3399_GRF_DSI_MODE,
.grf_dsi0_mode_reg = RK3399_GRF_SOC_CON22,
.max_data_lanes = 4,
--
2.6.3
[PATCH 2/3] drm/rockchip/dsi: enable the grf clk before writing grf registers
For RK3399, the grf clk should be enabled before writing grf registers,
otherwise the register value can not be changed.
Signed-off-by: Chris Zhong
---
drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 24
1 file changed, 24 insertions(+)
diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
index f84f9ae..d8f24f2 100644
--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
@@ -291,6 +291,7 @@ struct dw_mipi_dsi {
struct regmap *grf_regmap;
void __iomem *base;
+ struct clk *grf_clk;
struct clk *pllref_clk;
struct clk *pclk;
struct clk *phy_cfg_clk;
@@ -979,6 +980,16 @@ static void dw_mipi_dsi_encoder_enable(struct drm_encoder
*encoder)
dw_mipi_dsi_dphy_interface_config(dsi);
dw_mipi_dsi_clear_err(dsi);
+ /*
+* For the RK3399, the clk of grf must be enabled before writing grf
+* register.
+*/
+ ret = clk_prepare_enable(dsi->grf_clk);
+ if (ret) {
+ dev_err(dsi->dev, "Failed to enable grf_clk\n");
+ return;
+ }
+
if (pdata->grf_dsi0_mode_reg)
regmap_write(dsi->grf_regmap, pdata->grf_dsi0_mode_reg,
pdata->grf_dsi0_mode);
@@ -1003,6 +1014,8 @@ static void dw_mipi_dsi_encoder_enable(struct drm_encoder
*encoder)
regmap_write(dsi->grf_regmap, pdata->grf_switch_reg, val);
dev_dbg(dsi->dev, "vop %s output to dsi0\n", (mux) ? "LIT" : "BIG");
dsi->dpms_mode = DRM_MODE_DPMS_ON;
+
+ clk_disable_unprepare(dsi->grf_clk);
}
static int
@@ -1238,6 +1251,17 @@ static int dw_mipi_dsi_bind(struct device *dev, struct
device *master,
dev_dbg(dev, "have not phy_cfg_clk\n");
}
+ dsi->grf_clk = devm_clk_get(dev, "grf");
+ if (IS_ERR(dsi->grf_clk)) {
+ ret = PTR_ERR(dsi->grf_clk);
+ if (ret != -ENOENT) {
+ dev_err(dev, "Unable to get grf_clk: %d\n", ret);
+ return ret;
+ }
+ dsi->grf_clk = NULL;
+ dev_dbg(dev, "have not grf_clk\n");
+ }
+
ret = clk_prepare_enable(dsi->pllref_clk);
if (ret) {
dev_err(dev, "%s: Failed to enable pllref_clk\n", __func__);
--
2.6.3
[PATCH 1/3] dt-bindings: add the grf clock for dw-mipi-dsi
For RK3399, the grf clock should be controlled by dw-mipi-dsi driver, add the description for this clock. Signed-off-by: Chris Zhong --- .../devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt b/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt index 188f6f7..7e17a60 100644 --- a/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt +++ b/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt @@ -10,7 +10,7 @@ Required properties: - interrupts: Represent the controller's interrupt to the CPU(s). - clocks, clock-names: Phandles to the controller's pll reference clock(ref) and APB clock(pclk). For RK3399, a phy config clock - (phy_cfg) is additional required. As described in [1]. + (phy_cfg) and a grf clock(grf) are additional required. As described in [1]. - rockchip,grf: this soc should set GRF regs to mux vopl/vopb. - ports: contain a port node with endpoint definitions as defined in [2]. For vopb,set the reg = <0> and set the reg = <1> for vopl. -- 2.6.3
Re: [RFC 2/2] fanotify: emit FAN_MODIFY_DIR on filesystem changes
Filip Štědronský : > there are basically two classes of uses for a fantotify-like > interface: > > (1) Keeping an up-to-date representation of the file system. For this, > superblock watches are clearly what you want. > > [...] > > All those factors speak greatly in favour of superblock > watches. > > (2) Tracking filesystem *activity*. Now you are not building > an image of current filesystem state but rather a log of what > happened. Perhaps you are also interested in who > (user/process/...) did what. Permission events also fit mostly in > this category. > > For those it *might* make sense to have mount-scoped watches, for > example if you want to monitor only one container or a subset of > processes. > > We both concentrate on the first but we shouldn't forget about the > second, which was one of the original motivations for fanotify. My (employer's) needs are centered around (2). We definitely crave permission events with a filesystem scope. At the moment, you can avoid permission checks with a simple unshare command (https://lkml.org/lkml/2016/12/21/144>). So I must be able to see everything that is happening in my universe. It might also be useful to monitor a subuniverse of mine, but the former need is critical at the moment. As for "who (user/process/...) did what", the fanotify API is flawed in that we don't have a CLOSE_WRITE_PERM event. The hit-and-run process is long gone by the time we receive the event. That's more of a rule than an exception. Marko
[PATCH 1/2] mmc: core: guard dereference of optional parameter
Various functions take as parameter an optional pointer. Pointer
should be guarded with non-NULL check before dereferencing.
Add non-NULL check before dereference of pointer.
Signed-off-by: Tobin C. Harding
---
drivers/mmc/core/sdio_io.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/mmc/core/sdio_io.c b/drivers/mmc/core/sdio_io.c
index 74195d7..3482314 100644
--- a/drivers/mmc/core/sdio_io.c
+++ b/drivers/mmc/core/sdio_io.c
@@ -373,7 +373,8 @@ u8 sdio_readb(struct sdio_func *func, unsigned int addr,
int *err_ret)
u8 val;
if (!func) {
- *err_ret = -EINVAL;
+ if (err_ret)
+ *err_ret = -EINVAL;
return 0xFF;
}
@@ -407,7 +408,8 @@ void sdio_writeb(struct sdio_func *func, u8 b, unsigned int
addr, int *err_ret)
int ret;
if (!func) {
- *err_ret = -EINVAL;
+ if (err_ret)
+ *err_ret = -EINVAL;
return;
}
@@ -635,7 +637,8 @@ unsigned char sdio_f0_readb(struct sdio_func *func,
unsigned int addr,
unsigned char val;
if (!func) {
- *err_ret = -EINVAL;
+ if (err_ret)
+ *err_ret = -EINVAL;
return 0xFF;
}
@@ -673,7 +676,8 @@ void sdio_f0_writeb(struct sdio_func *func, unsigned char
b, unsigned int addr,
int ret;
if (!func) {
- *err_ret = -EINVAL;
+ if (err_ret)
+ *err_ret = -EINVAL;
return;
}
--
2.7.4
[PATCH 0/2] mmc: core: null pointer dereference bug
Various functions take as parameter an optional pointer. Pointer should be guarded with non-NULL check before dereferencing. While fixing this bug it was found that the file contains multiple functions doing variations on the same thing, sdio_readb(), sdio_writeb(), sdio_readw(), sdio_writew() etc. Although the functions have very similar logic the code is laid out in a variety of ways. This makes it overly complicated to read. There is a already a nice clean chunk of code, if we use this format for all instances then we will have cleaned up the code, reduced the line count and lessened the cognitive load required while reading. Patch 01 adds non-NULL check before dereference of pointer. Patch 02 cleans up the return code to be simple and uniform. Code has not been tested. sdio_io.c with patches applied has been checked with checkpatch, Sparse, and Smatch. Each patch has been applied and built on x86_64 and PowerPC Tobin C. Harding (2): mmc: core: guard dereference of optional parameter mmc: core: simplify return code drivers/mmc/core/sdio_io.c | 54 ++ 1 file changed, 21 insertions(+), 33 deletions(-) -- 2.7.4
[PATCH 2/2] mmc: core: simplify return code
File contains multiple functions doing variations on the same thing,
sdio_readb(), sdio_writeb()f, sdio_readw(), sdio_writew()
etc. Although the functions have very similar logic the code is laid
out in a variety of ways. This makes it overly complicated to
read. There is a already a nice clean chunk of code, if we use this
format for all instances then we will have cleaned up the code,
reduced the line count and lessened the cognitive load required while
reading. Less lines equals less bugs.
Pick the most simple and clear code flow and change all functions to
be the same.
Signed-off-by: Tobin C. Harding
---
drivers/mmc/core/sdio_io.c | 42 +-
1 file changed, 13 insertions(+), 29 deletions(-)
diff --git a/drivers/mmc/core/sdio_io.c b/drivers/mmc/core/sdio_io.c
index 3482314..d40744b 100644
--- a/drivers/mmc/core/sdio_io.c
+++ b/drivers/mmc/core/sdio_io.c
@@ -378,15 +378,11 @@ u8 sdio_readb(struct sdio_func *func, unsigned int addr,
int *err_ret)
return 0xFF;
}
- if (err_ret)
- *err_ret = 0;
-
ret = mmc_io_rw_direct(func->card, 0, func->num, addr, 0, &val);
- if (ret) {
- if (err_ret)
- *err_ret = ret;
+ if (err_ret)
+ *err_ret = ret;
+ if (ret)
return 0xFF;
- }
return val;
}
@@ -443,7 +439,7 @@ u8 sdio_writeb_readb(struct sdio_func *func, u8 write_byte,
if (err_ret)
*err_ret = ret;
if (ret)
- val = 0xff;
+ return 0xff;
return val;
}
@@ -531,15 +527,11 @@ u16 sdio_readw(struct sdio_func *func, unsigned int addr,
int *err_ret)
{
int ret;
- if (err_ret)
- *err_ret = 0;
-
ret = sdio_memcpy_fromio(func, func->tmpbuf, addr, 2);
- if (ret) {
- if (err_ret)
- *err_ret = ret;
+ if (err_ret)
+ *err_ret = ret;
+ if (ret)
return 0x;
- }
return le16_to_cpup((__le16 *)func->tmpbuf);
}
@@ -583,15 +575,11 @@ u32 sdio_readl(struct sdio_func *func, unsigned int addr,
int *err_ret)
{
int ret;
- if (err_ret)
- *err_ret = 0;
-
ret = sdio_memcpy_fromio(func, func->tmpbuf, addr, 4);
- if (ret) {
- if (err_ret)
- *err_ret = ret;
+ if (err_ret)
+ *err_ret = ret;
+ if (ret)
return 0x;
- }
return le32_to_cpup((__le32 *)func->tmpbuf);
}
@@ -642,15 +630,11 @@ unsigned char sdio_f0_readb(struct sdio_func *func,
unsigned int addr,
return 0xFF;
}
- if (err_ret)
- *err_ret = 0;
-
ret = mmc_io_rw_direct(func->card, 0, 0, addr, 0, &val);
- if (ret) {
- if (err_ret)
- *err_ret = ret;
+ if (err_ret)
+ *err_ret = ret;
+ if (ret)
return 0xFF;
- }
return val;
}
--
2.7.4
RE: [PATCH v2 net-next 4/5] sunvnet: count multicast packets
From: Shannon Nelson > Sent: 14 March 2017 17:25 ... > + if (unlikely(is_multicast_ether_addr(eth_hdr(skb)->h_dest))) > + dev->stats.multicast++; I'd guess that: dev->stats.multicast += is_multicast_ether_addr(eth_hdr(skb)->h_dest); generates faster code. Especially if is_multicast_ether_addr(x) is (*x >> 7). David
Re: [RFC PATCH 0/3] PM / Domains: Add support for devices that require multiple domains
On 13/03/17 14:42, Ulf Hansson wrote:
> On 13 March 2017 at 15:09, Jon Hunter wrote:
>> Hi Ulf,
>>
>> On 13/03/17 11:45, Ulf Hansson wrote:
>>> +Björn
>>>
>>> On 13 March 2017 at 10:37, Jon Hunter wrote:
Hi Rafael, Kevin, Ulf,
Looks like there is still some interest/needs in/for this. Any thoughts
on how we can move this forward?
>>>
>>> At the Linaro Connect last week, I was talking to Björn, Rajendra and
>>> Stephen more about these related issues.
>>>
>>> It definitely seems like we need to progress with this somehow,
>>> meaning we need a solution for being able to associate a device with
>>> more than one PM domain. In that context, I don't think genpd based on
>>> its current design, is a good fit to solve the problem.
>>>
>>> Instead I think we need something entirely new (perhaps some code can
>>> be borrowed from genpd), which is more similar to the clock/regulator
>>> framework. In other words, what you also were suggesting in a earlier
>>> reply.
>>> In this way, the driver/subsystem gains full flexibility of managing
>>> its device's PM domains, which seems like the best future-proof
>>> solution.
>>
>> I agree, I think that that would give us the most flexibility to handle
>> whatever scenario. However, I was thinking that we could still use the
>> genpd core to register pm-domains with and control. My thought was to
>> allow devices to have a bindings with multiple pm-domains ...
>>
>> dev-xyz {
>> ...
>> power-domains = <&domain-a>, <&domain-b>;
>> };
>
> This could work. However, let's involve DT maintainers to make sure we
> get their input to this. Perhaps they prefer a different approach.
No problem. I should point out the above is for the #power-domain-cells
= <0> case.
>>
>> Then in the genpd core we do having something like ...
>>
>> diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
>> index e697dec9d25b..d1ae6ddf4903 100644
>> --- a/drivers/base/power/domain.c
>> +++ b/drivers/base/power/domain.c
>> @@ -2026,6 +2026,15 @@ int genpd_dev_pm_attach(struct device *dev)
>> "samsung,power-domain", 0);
>> if (!pd_args.np)
>> return -ENOENT;
>> + } else if (ret > 1) {
>> + /*
>> +* If there are more than one PM domain defined for a device,
>> +* then these need to be manually controlled by the device
>> +* driver because the genpd core cannot bind a device with
>> +* more than one PM domain.
>> +*/
>> + dev_dbg(dev, "cannot add PM domains, %d detected!\n", ret);
>> + return 0;
>> }
>>
>> Then add some new public APIs for getting and controlling the pm-domains ...
>>
>> struct generic_pm_domain *pm_genpd_get(struct device *dev, char *name);
>> - Use 'dev->of_node' to look-up pm-domain if populated, else uses name.
>>
>> struct generic_pm_domain *of_pm_genpd_get(struct device *dev, int index);
>> void pm_genpd_put(struct generic_pm_domain *pd);
>> int pm_genpd_power_on(struct generic_pm_domain *pd);
>> int pm_genpd_power_off(struct generic_pm_domain *pd);
>> - Power on/off APIs would be synchronous types
>>
>> Are there any potential pitfalls of the above?
>
> So if I understand correctly, you would like to extend genpd with some
> new APIs. It's worth a try, however my main worries are these:
>
> 1) These new API must not be allowed to be abused.
> I have seen that before as when people try to handle some corner
> cases, I don't want to that to happen again. To avoid that, perhaps we
> should continue the re-structuring and thus move structures/datas that
> are currently public, to be internal to genpd. To get a clean
> interface.
OK, fair enough. Any in particular you are concerned about?
> 2) I wouldn't be surprised if we run into some tricky corner cases, as
> we get a mixture of devices handled by runtime PM and in some other
> cases via new APIs. Perhaps that can be sorted out!?
Right that is a concern, however, I think that in the long-term we would
be better off with the power-domains being controlled by the same
underlying code as opposed to something different.
Cheers
Jon
--
nvpublic
[PATCH v2 1/5] mm: add tlb_flush_mmu_free_batches
There are two places doing page free related to struct mmu_gather_batch:
1 in tlb_flush_mmu_free, where pages gathered in mmu_gather_batch list
are freed;
2 in tlb_flush_mmu_finish, where pages for the mmu_gather_batch
structure(let's call it the batch page) are freed.
There will be yet another place in the parallel free worker thread
introduced in the following patch to free both the pages pointed to by
the mmu_gather_batch list and the batch pages themselves. To avoid code
duplication, add a new function named tlb_flush_mmu_free_batches for
this purpose.
Another reason to add this function is that after the following patch,
cond_resched will need to be added at places where more than 10K pages
can be freed, i.e. in tlb_flush_mmu_free and the worker function.
Instead of adding cond_resched at multiple places, using a single
function to reduce code duplication.
There should be no functionality change.
Signed-off-by: Aaron Lu
---
mm/memory.c | 28 +---
1 file changed, 17 insertions(+), 11 deletions(-)
diff --git a/mm/memory.c b/mm/memory.c
index 14fc0b40f0bb..cdb2a53f251f 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -250,14 +250,25 @@ static void tlb_flush_mmu_tlbonly(struct mmu_gather *tlb)
__tlb_reset_range(tlb);
}
-static void tlb_flush_mmu_free(struct mmu_gather *tlb)
+static void tlb_flush_mmu_free_batches(struct mmu_gather_batch *batch_start,
+ bool free_batch_page)
{
- struct mmu_gather_batch *batch;
+ struct mmu_gather_batch *batch, *next;
- for (batch = &tlb->local; batch && batch->nr; batch = batch->next) {
- free_pages_and_swap_cache(batch->pages, batch->nr);
- batch->nr = 0;
+ for (batch = batch_start; batch; batch = next) {
+ next = batch->next;
+ if (batch->nr) {
+ free_pages_and_swap_cache(batch->pages, batch->nr);
+ batch->nr = 0;
+ }
+ if (free_batch_page)
+ free_pages((unsigned long)batch, 0);
}
+}
+
+static void tlb_flush_mmu_free(struct mmu_gather *tlb)
+{
+ tlb_flush_mmu_free_batches(&tlb->local, false);
tlb->active = &tlb->local;
}
@@ -273,17 +284,12 @@ void tlb_flush_mmu(struct mmu_gather *tlb)
*/
void tlb_finish_mmu(struct mmu_gather *tlb, unsigned long start, unsigned long
end)
{
- struct mmu_gather_batch *batch, *next;
-
tlb_flush_mmu(tlb);
/* keep the page table cache within bounds */
check_pgt_cache();
- for (batch = tlb->local.next; batch; batch = next) {
- next = batch->next;
- free_pages((unsigned long)batch, 0);
- }
+ tlb_flush_mmu_free_batches(tlb->local.next, true);
tlb->local.next = NULL;
}
--
2.7.4
[PATCH v2 4/5] mm: add force_free_pages in zap_pte_range
force_flush in zap_pte_range is set in the following 2 conditions:
1 When no more batches can be allocated (either due to no memory or
MAX_GATHER_BATCH_COUNT has reached) to store those to-be-freed page
pointers;
2 When a TLB_only flush is needed before dropping the PTE lock to avoid
a race condition as explained in commit 1cf35d47712d ("mm: split
'tlb_flush_mmu()' into tlb flushing and memory freeing parts").
Once force_flush is set, the pages accumulated thus far will all be
freed. Since there is no need to do page free for condition 2, add a new
variable named force_free_pages to decide if page free should be done
and it will only be set in condition 1.
With this change, the page accumulation will not be interrupted by
condition 2 anymore. In the meantime, rename force_flush to
force_flush_tlb for condition 2.
Signed-off-by: Aaron Lu
---
mm/memory.c | 20
1 file changed, 8 insertions(+), 12 deletions(-)
diff --git a/mm/memory.c b/mm/memory.c
index 19b25bb5f45b..83b38823aaba 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -1199,7 +1199,7 @@ static unsigned long zap_pte_range(struct mmu_gather *tlb,
struct zap_details *details)
{
struct mm_struct *mm = tlb->mm;
- int force_flush = 0;
+ int force_flush_tlb = 0, force_free_pages = 0;
int rss[NR_MM_COUNTERS];
spinlock_t *ptl;
pte_t *start_pte;
@@ -1239,7 +1239,7 @@ static unsigned long zap_pte_range(struct mmu_gather *tlb,
if (!PageAnon(page)) {
if (pte_dirty(ptent)) {
- force_flush = 1;
+ force_flush_tlb = 1;
set_page_dirty(page);
}
if (pte_young(ptent) &&
@@ -1251,7 +1251,7 @@ static unsigned long zap_pte_range(struct mmu_gather *tlb,
if (unlikely(page_mapcount(page) < 0))
print_bad_pte(vma, addr, ptent, page);
if (unlikely(__tlb_remove_page(tlb, page))) {
- force_flush = 1;
+ force_free_pages = 1;
addr += PAGE_SIZE;
break;
}
@@ -1279,18 +1279,14 @@ static unsigned long zap_pte_range(struct mmu_gather
*tlb,
arch_leave_lazy_mmu_mode();
/* Do the actual TLB flush before dropping ptl */
- if (force_flush)
+ if (force_flush_tlb) {
+ force_flush_tlb = 0;
tlb_flush_mmu_tlbonly(tlb);
+ }
pte_unmap_unlock(start_pte, ptl);
- /*
-* If we forced a TLB flush (either due to running out of
-* batch buffers or because we needed to flush dirty TLB
-* entries before releasing the ptl), free the batched
-* memory too. Restart if we didn't do everything.
-*/
- if (force_flush) {
- force_flush = 0;
+ if (force_free_pages) {
+ force_free_pages = 0;
tlb_flush_mmu_free(tlb);
if (addr != end)
goto again;
--
2.7.4
[PATCH v2 5/5] mm: add debugfs interface for parallel free tuning
Make it possible to set different values for async_free_threshold and
max_gather_batch_count through debugfs.
With this, we can do tests for different purposes:
1 Restore vanilla kernel bahaviour for performance comparison.
Set max_gather_batch_count to a value like 20 to effectively restore
the behaviour of vanilla kernel since this will make page gathered
always smaller than async_free_threshold(effectively disable parallel
free);
2 Debug purpose.
Set async_free_threshold to a very small value(like 128) to trigger
parallel free even on ordinary processes, ideal for debug purpose with
a virtual machine that doesn't have much memory assigned to it;
3 Performance tuning.
Use a different value for async_free_threshold and max_gather_batch_count
other than the default to test if parallel free performs better or worse.
Signed-off-by: Aaron Lu
---
mm/memory.c | 33 +++--
1 file changed, 31 insertions(+), 2 deletions(-)
diff --git a/mm/memory.c b/mm/memory.c
index 83b38823aaba..3a971cc1fc3b 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -183,6 +183,35 @@ static void check_sync_rss_stat(struct task_struct *task)
#ifdef HAVE_GENERIC_MMU_GATHER
+static unsigned long async_free_threshold = ASYNC_FREE_THRESHOLD;
+static unsigned long max_gather_batch_count = MAX_GATHER_BATCH_COUNT;
+
+#ifdef CONFIG_DEBUG_FS
+static int __init tlb_mmu_parallel_free_debugfs(void)
+{
+ umode_t mode = 0644;
+ struct dentry *dir;
+
+ dir = debugfs_create_dir("parallel_free", NULL);
+ if (!dir)
+ return -ENOMEM;
+
+ if (!debugfs_create_ulong("async_free_threshold", mode, dir,
+ &async_free_threshold))
+ goto fail;
+ if (!debugfs_create_ulong("max_gather_batch_count", mode, dir,
+ &max_gather_batch_count))
+ goto fail;
+
+ return 0;
+
+fail:
+ debugfs_remove_recursive(dir);
+ return -ENOMEM;
+}
+late_initcall(tlb_mmu_parallel_free_debugfs);
+#endif
+
static bool tlb_next_batch(struct mmu_gather *tlb)
{
struct mmu_gather_batch *batch;
@@ -193,7 +222,7 @@ static bool tlb_next_batch(struct mmu_gather *tlb)
return true;
}
- if (tlb->batch_count == MAX_GATHER_BATCH_COUNT)
+ if (tlb->batch_count == max_gather_batch_count)
return false;
batch = (void *)__get_free_pages(GFP_NOWAIT | __GFP_NOWARN, 0);
@@ -307,7 +336,7 @@ static void tlb_flush_mmu_free(struct mmu_gather *tlb)
{
struct batch_free_struct *batch_free = NULL;
- if (tlb->page_nr >= ASYNC_FREE_THRESHOLD)
+ if (tlb->page_nr >= async_free_threshold)
batch_free = kmalloc(sizeof(*batch_free),
GFP_NOWAIT | __GFP_NOWARN);
--
2.7.4
[PATCH v2 2/5] mm: parallel free pages
For regular processes, the time taken in its exit() path to free its
used memory is not a problem. But there are heavy ones that consume
several Terabytes memory and the time taken to free its memory could
last more than ten minutes.
To optimize this use case, a parallel free method is proposed and it is
based on the current gather batch free.
The current gather batch free works like this:
For each struct mmu_gather *tlb, there is a static buffer to store those
to-be-freed page pointers. The size is MMU_GATHER_BUNDLE, which is
defined to be 8. So if a tlb tear down doesn't free more than 8 pages,
that is all we need. If 8+ pages are to be freed, new pages will need
to be allocated to store those to-be-freed page pointers.
The structure used to describe the saved page pointers is called
struct mmu_gather_batch and tlb->local is of this type. tlb->local is
different than other struct mmu_gather_batch(es) in that the page
pointer array used by tlb->local points to the previouslly described
static buffer while the other struct mmu_gather_batch(es) page pointer
array points to the dynamically allocated pages.
These batches will form a singly linked list, starting from &tlb->local.
tlb->local.pages => tlb->pages(8 pointers)
\|/
next => batch1->pages => about 510 pointers
\|/
next => batch2->pages => about 510 pointers
\|/
next => batch3->pages => about 510 pointers
... ...
The proposed parallel free did this: if the process has many pages to be
freed, accumulate them in these struct mmu_gather_batch(es) one after
another till 256K pages are accumulated. Then take this singly linked
list starting from tlb->local.next off struct mmu_gather *tlb and free
them in a worker thread. The main thread can return to continue zap
other pages(after freeing pages pointed by tlb->local.pages).
Note that since we may be accumulating as many as 256K pages now, the
soft lockup on !CONFIG_PREEMPT issue which is fixed by
commit 53a59fc67f97 ("mm: limit mmu_gather batching to fix soft lockups
on !CONFIG_PREEMPT") can reappear. For that matter, add cond_resched()
in tlb_flush_mmu_free_batches where many pages can be freed.
Signed-off-by: Aaron Lu
---
include/asm-generic/tlb.h | 15 +++--
mm/memory.c | 57 ++-
2 files changed, 64 insertions(+), 8 deletions(-)
diff --git a/include/asm-generic/tlb.h b/include/asm-generic/tlb.h
index 4329bc6ef04b..7c2ac179cc47 100644
--- a/include/asm-generic/tlb.h
+++ b/include/asm-generic/tlb.h
@@ -78,13 +78,10 @@ struct mmu_gather_batch {
#define MAX_GATHER_BATCH \
((PAGE_SIZE - sizeof(struct mmu_gather_batch)) / sizeof(void *))
-/*
- * Limit the maximum number of mmu_gather batches to reduce a risk of soft
- * lockups for non-preemptible kernels on huge machines when a lot of memory
- * is zapped during unmapping.
- * 10K pages freed at once should be safe even without a preemption point.
- */
-#define MAX_GATHER_BATCH_COUNT (1UL/MAX_GATHER_BATCH)
+#define ASYNC_FREE_THRESHOLD (256*1024UL)
+#define MAX_GATHER_BATCH_COUNT \
+ DIV_ROUND_UP(ASYNC_FREE_THRESHOLD, MAX_GATHER_BATCH)
+#define PAGE_FREE_NR_TO_YIELD (1UL)
/* struct mmu_gather is an opaque type used by the mm code for passing around
* any data needed by arch specific code for tlb_remove_page.
@@ -108,6 +105,10 @@ struct mmu_gather {
struct page *__pages[MMU_GATHER_BUNDLE];
unsigned intbatch_count;
int page_size;
+ /* how many pages we have gathered to be freed */
+ unsigned intpage_nr;
+ /* list for spawned workers that do the free jobs */
+ struct list_headworker_list;
};
#define HAVE_GENERIC_MMU_GATHER
diff --git a/mm/memory.c b/mm/memory.c
index cdb2a53f251f..001c7720d773 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -228,6 +228,9 @@ void tlb_gather_mmu(struct mmu_gather *tlb, struct
mm_struct *mm, unsigned long
tlb->local.max = ARRAY_SIZE(tlb->__pages);
tlb->active = &tlb->local;
tlb->batch_count = 0;
+ tlb->page_nr= 0;
+
+ INIT_LIST_HEAD(&tlb->worker_list);
#ifdef CONFIG_HAVE_RCU_TABLE_FREE
tlb->batch = NULL;
@@ -254,22 +257,65 @@ static void tlb_flush_mmu_free_batches(struct
mmu_gather_batch *batch_start,
bool free_batch_page)
{
struct mmu_gather_batch *batch, *next;
+ int nr = 0;
for (batch = batch_start; batch; batch = next) {
next = batch->next;
if (batch->nr) {
free_pages_and_swap_cache(batch->pages, batch->nr);
+ nr += batch->nr;
batch->nr = 0;
}
- if (free_batch_page)
+ if (free_batch_page) {
free_pages((unsig
Re: [PATCH v2 2/3] printk: rename selected_console -> preferred_console
On Thu 2017-03-02 10:01:53, Steven Rostedt wrote: > On Thu, 2 Mar 2017 16:11:33 +0300 > Aleksey Makarov wrote: > > > The variable selected_console is set in __add_preferred_console() > > to point to the last console parameter that was added to the > > console_cmdline array. > > > > Rename it to preferred_console so that the name reflects the usage. > > As I said previously, I prefer "selected_console" but since > "__add_preferred_console()" sets it, I'm fine with this change. > Although, I would probably have changed that function to > "__add_selected_console()" :) If I get it correctly, the selected_console/preferred_console value is used to keep the console first in the console_drivers list. IMHO, the main effect is that each line will first appear on this console, see call_console_drivers(). But the message will still appear also on all other enabled consoles. From this point, the name "preferred" sounds better to me. More consoles are selected (enabled) and only one is preferred (first). Well, I am not a native speaker and might be wrong. Also it is possible that I missed something. Anyway, the change looks fine to me. Acked-by: Petr Mladek Best Regards, Petr
Re: [PATCH v4 05/11] mm: thp: enable thp migration in generic path
On Tue, Mar 14, 2017 at 10:55 PM, Zi Yan wrote:
include/linux/swapops.h:223:2: warning: missing braces around initializer
[-Wmissing-braces]
>> return (pmd_t){ 0 };
>> ^
>>include/linux/swapops.h:223:2: warning: (near initialization for
>> '(anonymous).pmd') [-Wmissing-braces]
>
> I do not have any warning with gcc 6.3.0. This seems to be a GCC bug
> (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53119).
I guess you need
return (pmd_t) { { 0, }};
to kill the warning.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
[PATCH v2 3/5] mm: use a dedicated workqueue for the free workers
Introduce a workqueue for all the free workers so that user can fine
tune how many workers can be active through sysfs interface: max_active.
More workers will normally lead to better performance, but too many can
cause severe lock contention.
Note that since the zone lock is global, the workqueue is also global
for all processes, i.e. if we set 8 to max_active, we will have at most
8 workers active for all processes that are doing munmap()/exit()/etc.
Signed-off-by: Aaron Lu
---
mm/memory.c | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/mm/memory.c b/mm/memory.c
index 001c7720d773..19b25bb5f45b 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -253,6 +253,19 @@ static void tlb_flush_mmu_tlbonly(struct mmu_gather *tlb)
__tlb_reset_range(tlb);
}
+static struct workqueue_struct *batch_free_wq;
+static int __init batch_free_wq_init(void)
+{
+ batch_free_wq = alloc_workqueue("batch_free_wq",
+ WQ_UNBOUND | WQ_SYSFS, 0);
+ if (!batch_free_wq) {
+ pr_warn("failed to create workqueue batch_free_wq\n");
+ return -ENOMEM;
+ }
+ return 0;
+}
+subsys_initcall(batch_free_wq_init);
+
static void tlb_flush_mmu_free_batches(struct mmu_gather_batch *batch_start,
bool free_batch_page)
{
@@ -306,7 +319,7 @@ static void tlb_flush_mmu_free(struct mmu_gather *tlb)
batch_free->batch_start = tlb->local.next;
INIT_WORK(&batch_free->work, batch_free_work);
list_add_tail(&batch_free->list, &tlb->worker_list);
- queue_work(system_unbound_wq, &batch_free->work);
+ queue_work(batch_free_wq, &batch_free->work);
tlb->batch_count = 0;
tlb->local.next = NULL;
--
2.7.4
[PATCH v2 0/5] mm: support parallel free of memory
For regular processes, the time taken in its exit() path to free its used memory is not a problem. But there are heavy ones that consume several Terabytes memory and the time taken to free its memory in its exit() path could last more than ten minutes if THP is not used. As Dave Hansen explained why do this in kernel: " One of the places we saw this happen was when an app crashed and was exit()'ing under duress without cleaning up nicely. The time that it takes to unmap a few TB of 4k pages is pretty excessive. " To optimize this use case, a parallel free method is proposed here and it is based on the current gather batch free(the following description is taken from patch 2/5's changelog). The current gather batch free works like this: For each struct mmu_gather *tlb, there is a static buffer to store those to-be-freed page pointers. The size is MMU_GATHER_BUNDLE, which is defined to be 8. So if a tlb tear down doesn't free more than 8 pages, that is all we need. If 8+ pages are to be freed, new pages will need to be allocated to store those to-be-freed page pointers. The structure used to describe the saved page pointers is called struct mmu_gather_batch and tlb->local is of this type. tlb->local is different than other struct mmu_gather_batch(es) in that the page pointer array used by tlb->local points to the previouslly described static buffer while the other struct mmu_gather_batch(es) page pointer array points to the dynamically allocated pages. These batches will form a singly linked list, starting from &tlb->local. tlb->local.pages => tlb->pages(8 pointers) \|/ next => batch1->pages => about 510 pointers \|/ next => batch2->pages => about 510 pointers \|/ next => batch3->pages => about 510 pointers ... ... The proposed parallel free did this: if the process has many pages to be freed, accumulate them in these struct mmu_gather_batch(es) one after another till 256K pages are accumulated. Then take this singly linked list starting from tlb->local.next off struct mmu_gather *tlb and free them in a worker thread. The main thread can return to continue zap other pages(after freeing pages pointed by tlb->local.pages). A test program that did a single malloc() of 320G memory is used to see how useful the proposed parallel free solution is, the time calculated is for the free() call. Test machine is a Haswell EX which has 4nodes/72cores/144threads with 512G memory. All tests are done with THP disabled. kernel time v4.10 10.8s ±2.8% this patch(with default setting) 5.795s ±5.8% Patch 3/5 introduced a dedicated workqueue for the free workers and here are more results when setting different values for max_active of this workqueue: max_active: time 1 8.9s ±0.5% 2 5.65s ±5.5% 4 4.84s ±0.16% 8 4.77s ±0.97% 164.85s ±0.77% 326.21s ±0.46% Comments are welcome and appreciated. v2 changes: Nothing major, only minor ones. - rebased on top of v4.11-rc2-mmotm-2017-03-14-15-41; - use list_add_tail instead of list_add to add worker to tlb's worker list so that when doing flush, the first queued worker gets flushed first(based on the comsumption that the first queued worker has a better chance of finishing its job than those later queued workers); - use bool instead of int for variable free_batch_page in function tlb_flush_mmu_free_batches; - style change according to ./scripts/checkpatch; - reword some of the changelogs to make it more readable. v1 is here: https://lkml.org/lkml/2017/2/24/245 Aaron Lu (5): mm: add tlb_flush_mmu_free_batches mm: parallel free pages mm: use a dedicated workqueue for the free workers mm: add force_free_pages in zap_pte_range mm: add debugfs interface for parallel free tuning include/asm-generic/tlb.h | 15 ++--- mm/memory.c | 141 +++--- 2 files changed, 128 insertions(+), 28 deletions(-) -- 2.7.4
Re: [PATCH 1/3] dt-bindings: add the grf clock for dw-mipi-dsi
Am Mittwoch, 15. März 2017, 16:42:30 CET schrieb Chris Zhong: > For RK3399, the grf clock should be controlled by dw-mipi-dsi driver, > add the description for this clock. > > Signed-off-by: Chris Zhong > --- > > .../devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt | 2 > +- 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git > a/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.t > xt > b/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.t > xt index 188f6f7..7e17a60 100644 > --- > a/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.t > xt +++ > b/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.t > xt @@ -10,7 +10,7 @@ Required properties: > - interrupts: Represent the controller's interrupt to the CPU(s). > - clocks, clock-names: Phandles to the controller's pll reference >clock(ref) and APB clock(pclk). For RK3399, a phy config clock > - (phy_cfg) is additional required. As described in [1]. > + (phy_cfg) and a grf clock(grf) are additional required. As described in > [1]. your "grf" clock is optional, as it is not present on all socs (like the rk3288) so should probably move to a separate section and not be in the required properties Heiko
Re: [RFC PATCH 0/3] PM / Domains: Add support for devices that require multiple domains
Hi Rajendra,
On 15/03/17 03:47, Nayak, Rajendra wrote:
> Hey Jon,
>
Looks like there is still some interest/needs in/for this. Any thoughts
on how we can move this forward?
>>>
>>> At the Linaro Connect last week, I was talking to Björn, Rajendra and
>>> Stephen more about these related issues.
>>>
>>> It definitely seems like we need to progress with this somehow,
>>> meaning we need a solution for being able to associate a device with
>>> more than one PM domain. In that context, I don't think genpd based on
>>> its current design, is a good fit to solve the problem.
>>>
>>> Instead I think we need something entirely new (perhaps some code can
>>> be borrowed from genpd), which is more similar to the clock/regulator
>>> framework. In other words, what you also were suggesting in a earlier
>>> reply.
>>> In this way, the driver/subsystem gains full flexibility of managing
>>> its device's PM domains, which seems like the best future-proof
>>> solution.
>>
>> I agree, I think that that would give us the most flexibility to handle
>> whatever scenario. However, I was thinking that we could still use the
>> genpd core to register pm-domains with and control. My thought was to
>> allow devices to have a bindings with multiple pm-domains ...
>>
>> dev-xyz {
>> ...
>> power-domains = <&domain-a>, <&domain-b>;
>> };
>>
>> Then in the genpd core we do having something like ...
>>
>> diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
>> index e697dec9d25b..d1ae6ddf4903 100644
>> --- a/drivers/base/power/domain.c
>> +++ b/drivers/base/power/domain.c
>> @@ -2026,6 +2026,15 @@ int genpd_dev_pm_attach(struct device *dev)
>>
>> "samsung,power-domain", 0);
>> if (!pd_args.np)
>> return -ENOENT;
>> + } else if (ret > 1) {
>> + /*
>> +* If there are more than one PM domain defined for a
>> device,
>> +* then these need to be manually controlled by the
>> device
>> +* driver because the genpd core cannot bind a device
>> with
>> +* more than one PM domain.
>> +*/
>> + dev_dbg(dev, "cannot add PM domains, %d detected!\n",
>> ret);
>> + return 0;
>> }
>>
>> Then add some new public APIs for getting and controlling the
>> pm-domains ...
>>
>> struct generic_pm_domain *pm_genpd_get(struct device *dev, char *name);
>> - Use 'dev->of_node' to look-up pm-domain if populated, else uses name.
>>
>> struct generic_pm_domain *of_pm_genpd_get(struct device *dev, int index);
>> void pm_genpd_put(struct generic_pm_domain *pd);
>> int pm_genpd_power_on(struct generic_pm_domain *pd);
>> int pm_genpd_power_off(struct generic_pm_domain *pd);
>> - Power on/off APIs would be synchronous types
>
> These would also need some kind of usecounting I guess, since genpd
> otherwise relies on runtime PM to do the usecounting.
Yes exactly.
> This overall seems like a reasonable approach to solve the problem we
> have. While we discussed this approach at connect, we thought it would
> be a good idea to bring out some RFC on these lines to get the
> discussion going. Do you think you would be able to work on some quick
> RFC around these lines, else if you think you would be busy in the near
> term I can help with hacking up the changes as well.
Yes I plan too. I will let you know if I get side tracked on something else.
Cheers!
Jon
--
nvpublic
Re: [PATCH v6 00/11] perf: arm64: Support for Hisilicon SoC Hardware event counters
Please have a look at this patch series. Looking forward for any feedback and comments. Thanks, Anurup On Friday 10 March 2017 11:55 AM, Anurup M wrote: Provide Support for Hisilicon SoC(HiP05/06/07) Hardware event counters. The Hisilicon SoC HiP0x series has many uncore or non-CPU performance events and counters units. This v6 version is rebased to 4.11-rc1. This patch series is implemented refering to arm-cci, Intel/AMD uncore and also the cavium thunderX and xgene uncore pmu patches. Support for Hisilicon L3 cache(L3C) and Miscellaneous nodes(MN) hardware events and counters are added in this implementation. The uncore PMU units are registered as separate PMUs. e.g. in the case of L3 cache, which consist of 4 banks/instances, each bank is registered with perf as separate PMU, as each bank have separate control registers and interrupts. These units are also not CPU affine in the current chip versions. The Hisilicon uncore PMUs can be found under /sys/bus/event_source/devices. The counters are exported via sysfs in the corresponding events files under the PMU directory so the perf tool can list the event names. There is no counter overflow IRQ support in hardware for these uncore PMUs. So the driver use poll method using hrtimer to avoid overflow. ToDo: 1) ACPI probe and reset support. Version history --- v6 -- - Rebase to 4.11-rc1 - Modify Copyright year to 2017. v5 -- - Use hrtimer to avoid overflow as MN counter overflow IRQ is broken in hardware. - Remove IRQ handling of MN in driver and update pmu dt-bindings. - Fix reveiw comments in v4 version. v4 -- - Counter overflow IRQ handling for MN PMU. - Use hrtimer to avoid counter overflow in L3 Cache PMU. - Use hisi-cpu- and hisi-io- for djtag compatible field. - Fix reveiw comments in v3 version. v3 -- - Fix review comments of v2 version. - Handle event groups. Do not allow group of mixed PMUs. - Use hip0x prefix for compatible names. - Fix all sparse and gcc W=1 warnings. v2 -- - Fix review comments of v1 version. - Move djtag driver to drivers/perf/hisilicon. - Have separate PMU instance for each L3 cache banks. - Modify device properties in DTS as per review comments. - Handle hardware version difference. - Change compatible names of djtag so use prefix hisi- and remove chip version as driver only depend on djtag hw version. - use devm_kzalloc. - Remove DDRC changes in this series. As the DDRC PMU doesnot depend on djtag it will be send separately. v1 -- -Initial version with support for L3C, MN and DDRC event counters -Djtag driver is used to access registers of L3 cache and MN. Anurup M (8): arm64: MAINTAINERS: hisi: Add hisilicon SoC PMU support dt-bindings: perf: hisi: Add Devicetree bindings for Hisilicon SoC PMU Documentation: perf: hisi: Documentation for HiP05/06/07 PMU event counting. drivers: perf: hisi: Update Kconfig for Hisilicon PMU support drivers: perf: hisi: Add support for Hisilicon SoC event counters drivers: perf: hisi: use poll method to avoid L3C counter overflow drivers: perf: hisi: use poll method when no IRQ for MN counter overflow dts: arm64: hip07: Add Hisilicon SoC PMU support Shaokun Zhang (1): drivers: perf: hisi: Miscellanous node(MN) event counting in perf Tan Xiaojun (2): dt-bindings: hisi: Add Hisilicon HiP05/06/07 Djtag dts bindings drivers: perf: hisi: Add support for Hisilicon Djtag driver .../devicetree/bindings/arm/hisilicon/djtag.txt| 76 ++ .../devicetree/bindings/arm/hisilicon/pmu.txt | 87 +++ Documentation/perf/hisi-pmu.txt| 76 ++ MAINTAINERS| 9 + arch/arm64/boot/dts/hisilicon/hip07.dtsi | 79 +++ drivers/perf/Kconfig | 8 + drivers/perf/Makefile | 1 + drivers/perf/hisilicon/Makefile| 1 + drivers/perf/hisilicon/djtag.c | 773 + drivers/perf/hisilicon/djtag.h | 42 ++ drivers/perf/hisilicon/hisi_uncore_l3c.c | 653 + drivers/perf/hisilicon/hisi_uncore_mn.c| 528 ++ drivers/perf/hisilicon/hisi_uncore_pmu.c | 445 drivers/perf/hisilicon/hisi_uncore_pmu.h | 137 14 files changed, 2915 insertions(+) create mode 100644 Documentation/devicetree/bindings/arm/hisilicon/djtag.txt create mode 100644 Documentation/devicetree/bindings/arm/hisilicon/pmu.txt create mode 100644 Documentation/perf/hisi-pmu.txt create mode 100644 drivers/perf/hisilicon/Makefile create mode 100644 drivers/perf/hisilicon/djtag.c create mode 100644 drivers/perf/hisilicon/djtag.h create mode 100644 drivers/perf/hisilicon/hisi_uncore_l3c.c create mode 100644 drivers/perf/hisilicon/hisi_uncore_mn.c create mode 100644 drivers/perf/hisilicon/hisi_uncore_pmu.c create mode 100644 drivers/perf/hisilicon/hisi_unco
RE: [RFC PATCH] iommu/dma: check pci host bridge dma_mask for IOVA allocation
Hi Robin, I tried applying [1]:http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1306545.ht ml [3]:http://www.spinics.net/lists/arm-kernel/msg566947.html Because of 3 its crashing on our platform. (with SDHCI running with iommu both enabled and disabled) [ 19.925018] PC is at sdhci_send_command+0x648/0xb30 [ 19.930048] LR is at sdhci_send_command+0x588/0xb30 [ 19.935078] pc : [] lr : [] pstate: a1c5 [ 19.942707] sp : 80097ff1ede0 [ 19.946123] x29: 80097ff1ede0 x28: [ 19.951623] x27: 0001 x26: 08923ca8 [ 19.957124] x25: 8009750dc0d8 x24: 8009750dacc0 [ 19.962625] x23: 00418958 x22: 0003 [ 19.968125] x21: 8009750dc118 x20: 8009750dc198 [ 19.973626] x19: 8009750dac00 x18: 0400 [ 19.979126] x17: x16: [ 19.984627] x15: 8009764e4880 x14: 800976811548 [ 19.990128] x13: 0008 x12: 7e0025ff9580 [ 19.995628] x11: 800976d28080 x10: 0840 [ 20.001129] x9 : 0040 x8 : 800976801020 [ 20.006629] x7 : 0009d000 x6 : 08441358 [ 20.012130] x5 : x4 : [ 20.017631] x3 : 800976465080 x2 : [ 20.023130] x1 : 7e0025ce7802 x0 : ffe4 [ 20.028630] [ 20.030165] ---[ end trace cd394f1ca2a1b19b ]--- [ 20.034925] Call trace: [ 20.037446] Exception stack(0x80097ff1ec10 to 0x80097ff1ed40) [ 20.044089] ec00: 8009750dac00 0001 [ 20.052165] ec20: 80097ff1ede0 085c9cb0 0001 [ 20.060242] ec40: 80097ff1ec90 084402b4 800976421000 800976465040 [ 20.068318] ec60: 800976465040 80097659c850 80097653d810 [ 20.076393] ec80: 0001 800973cb9300 80097ff1ecb0 08440324 [ 20.084470] eca0: 800976421000 01c0 ffe4 7e0025ce7802 [ 20.092547] ecc0: 800976465080 [ 20.100623] ece0: 08441358 0009d000 800976801020 0040 [ 20.108699] ed00: 0840 800976d28080 7e0025ff9580 0008 [ 20.116776] ed20: 800976811548 8009764e4880 [ 20.124853] [] sdhci_send_command+0x648/0xb30 [ 20.130959] [] sdhci_irq+0x9e8/0xa20 [ 20.136259] [] __handle_irq_event_percpu+0x9c/0x128 [ 20.142901] [] handle_irq_event_percpu+0x1c/0x58 [ 20.149275] [] handle_irq_event+0x48/0x78 [ 20.155022] [] handle_fasteoi_irq+0xb8/0x1a0 [ 20.161036] [] generic_handle_irq+0x24/0x38 [ 20.166962] [] __handle_domain_irq+0x5c/0xb8 [ 20.172977] [] gic_handle_irq+0xbc/0x168 Regards, Oza. -Original Message- From: Oza Oza [mailto:oza@broadcom.com] Sent: Tuesday, March 14, 2017 5:16 PM To: 'Robin Murphy'; 'Joerg Roedel' Cc: 'io...@lists.linux-foundation.org'; 'linux-kernel@vger.kernel.org'; 'linux-arm-ker...@lists.infradead.org'; 'bcm-kernel-feedback-l...@broadcom.com'; 'a...@arndb.de'; 'Nikita Yushchenko' Subject: RE: [RFC PATCH] iommu/dma: check pci host bridge dma_mask for IOVA allocation My responses inline: -Original Message- From: Robin Murphy [mailto:robin.mur...@arm.com] Sent: Tuesday, March 14, 2017 4:27 PM To: Oza Pawandeep; Joerg Roedel Cc: io...@lists.linux-foundation.org; linux-kernel@vger.kernel.org; linux-arm-ker...@lists.infradead.org; bcm-kernel-feedback-l...@broadcom.com; a...@arndb.de; Nikita Yushchenko Subject: Re: [RFC PATCH] iommu/dma: check pci host bridge dma_mask for IOVA allocation On 14/03/17 08:48, Oza Pawandeep wrote: > It is possible that PCI device supports 64-bit DMA addressing, and > thus it's driver sets device's dma_mask to DMA_BIT_MASK(64), however > PCI host bridge may have limitations on the inbound transaction > addressing. As an example, consider NVME SSD device connected to > iproc-PCIe controller. Aw heck, not another one :( > Currently, the IOMMU DMA ops only considers PCI device dma_mask when > allocating an IOVA. This is particularly problematic on > ARM/ARM64 SOCs where the IOMMU (i.e. SMMU) translates IOVA to PA for > in-bound transactions only after PCI Host has forwarded these > transactions on SOC IO bus. This means on such ARM/ARM64 SOCs the IOVA > of in-bound transactions has to honor the addressing restrictions of > the PCI Host. Depending on whether this most closely matches the R-Car situation[1] or the X-Gene situation[2], this may not address the real problem at all (if the non-IOMMU case is also affected). Either way it also fails to help non-PCI devices which can face the exact same problem. I am not fully aware of R-car and X-gene situation, but for iproc based SOCs, our pcie host floats addresses in higher order dma_mask is set. > This patch tries to solve above described IOVA allocation problem by: > 1. Adding
Re: crypto: deadlock between crypto_alg_sem/rtnl_mutex/genl_mutex
On Tue, Mar 14, 2017 at 4:25 PM, Sowmini Varadhan
wrote:
> On (03/14/17 09:14), Dmitry Vyukov wrote:
>> Another one now involving rds_tcp_listen_stop
>:
>> kworker/u4:1/19 is trying to acquire lock:
>> (sk_lock-AF_INET){+.+.+.}, at: [] lock_sock
>> include/net/sock.h:1460 [inline]
>> (sk_lock-AF_INET){+.+.+.}, at: []
>> rds_tcp_listen_stop+0x5c/0x150 net/rds/tcp_listen.c:288
>>
>> but task is already holding lock:
>> (rtnl_mutex){+.+.+.}, at: [] rtnl_lock+0x17/0x20
>> net/core/rtnetlink.c:70
>
> Is this also a false positive?
>
> genl_lock_dumpit takes the genl_lock and then waits on the rtnl_lock
> (e.g., out of tipc_nl_bearer_dump).
>
> netdev_run_todo takes the rtnl_lock and then wants lock_sock()
> for the TCP/IPv4 socket.
>
> Why is lockdep seeing a circular dependancy here? Same pattern
> seems to be happening for
> http://www.spinics.net/lists/netdev/msg423368.html
> and maybe also http://www.spinics.net/lists/netdev/msg423323.html?
>
> --Sowmini
>
>> Chain exists of:
>> sk_lock-AF_INET --> genl_mutex --> rtnl_mutex
>>
>> Possible unsafe locking scenario:
>>
>>CPU0CPU1
>>
>> lock(rtnl_mutex);
>>lock(genl_mutex);
>>lock(rtnl_mutex);
>> lock(sk_lock-AF_INET);
>>
>> *** DEADLOCK ***
>>
>> 4 locks held by kworker/u4:1/19:
>> #0: ("%s""netns"){.+.+.+}, at: []
>> __write_once_size include/linux/compiler.h:283 [inline]
>> #0: ("%s""netns"){.+.+.+}, at: [] atomic64_set
>> arch/x86/include/asm/atomic64_64.h:33 [inline]
>> #0: ("%s""netns"){.+.+.+}, at: [] atomic_long_set
>> include/asm-generic/atomic-long.h:56 [inline]
>> #0: ("%s""netns"){.+.+.+}, at: [] set_work_data
>> kernel/workqueue.c:617 [inline]
>> #0: ("%s""netns"){.+.+.+}, at: []
>> set_work_pool_and_clear_pending kernel/workqueue.c:644 [inline]
>> #0: ("%s""netns"){.+.+.+}, at: []
>> process_one_work+0xab3/0x1c10 kernel/workqueue.c:2089
>> #1: (net_cleanup_work){+.+.+.}, at: []
>> process_one_work+0xb07/0x1c10 kernel/workqueue.c:2093
>> #2: (net_mutex){+.+.+.}, at: []
>> cleanup_net+0x22b/0xa90 net/core/net_namespace.c:429
>> #3: (rtnl_mutex){+.+.+.}, at: []
>> rtnl_lock+0x17/0x20 net/core/rtnetlink.c:70
After I've applied the patch these reports stopped to happen, and I
have not seem any other reports that look relevant.
However, it there was one, but it looks like a different issue and it
was probably masked by massive amounts of original deadlock reports:
[ INFO: possible circular locking dependency detected ]
4.10.0+ #29 Not tainted
---
syz-executor5/29222 is trying to acquire lock:
(genl_mutex){+.+.+.}, at: [] genl_lock
net/netlink/genetlink.c:32 [inline]
(genl_mutex){+.+.+.}, at: []
genl_family_rcv_msg+0xdae/0x1040 net/netlink/genetlink.c:547
but task is already holding lock:
(rtnl_mutex){+.+.+.}, at: [] rtnl_lock+0x17/0x20
net/core/rtnetlink.c:70
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (rtnl_mutex){+.+.+.}:
validate_chain kernel/locking/lockdep.c:2267 [inline]
__lock_acquire+0x2149/0x3430 kernel/locking/lockdep.c:3340
lock_acquire+0x2a1/0x630 kernel/locking/lockdep.c:3755
__mutex_lock_common kernel/locking/mutex.c:756 [inline]
__mutex_lock+0x172/0x1730 kernel/locking/mutex.c:893
mutex_lock_nested+0x16/0x20 kernel/locking/mutex.c:908
rtnl_lock+0x17/0x20 net/core/rtnetlink.c:70
nl80211_dump_wiphy+0x45/0x6d0 net/wireless/nl80211.c:1946
genl_lock_dumpit+0x68/0x90 net/netlink/genetlink.c:479
netlink_dump+0x54d/0xd40 net/netlink/af_netlink.c:2168
__netlink_dump_start+0x4e5/0x760 net/netlink/af_netlink.c:2258
genl_family_rcv_msg+0xd9d/0x1040 net/netlink/genetlink.c:546
genl_rcv_msg+0xa6/0x140 net/netlink/genetlink.c:620
netlink_rcv_skb+0x2ab/0x390 net/netlink/af_netlink.c:2339
genl_rcv+0x28/0x40 net/netlink/genetlink.c:631
netlink_unicast_kernel net/netlink/af_netlink.c:1272 [inline]
netlink_unicast+0x514/0x730 net/netlink/af_netlink.c:1298
netlink_sendmsg+0xa9f/0xe50 net/netlink/af_netlink.c:1844
sock_sendmsg_nosec net/socket.c:633 [inline]
sock_sendmsg+0xca/0x110 net/socket.c:643
___sys_sendmsg+0x8fa/0x9f0 net/socket.c:1985
__sys_sendmsg+0x138/0x300 net/socket.c:2019
SYSC_sendmsg net/socket.c:2030 [inline]
SyS_sendmsg+0x2d/0x50 net/socket.c:2026
do_syscall_64+0x2e8/0x930 arch/x86/entry/common.c:281
return_from_SYSCALL_64+0x0/0x7a
-> #0 (genl_mutex){+.+.+.}:
check_prev_add kernel/locking/lockdep.c:1830 [inline]
check_prevs_add+0xa8f/0x19f0 kernel/locking/lockdep.c:1940
validate_chain kernel/locking/lockdep.c:2267 [inline]
__lock_acquire+0x2149/0x3430 kernel/locking/lockdep.c:3340
lock_acquire+0x2a1/0x630 kernel/locking/lockdep.c:3755
__mu
[PATCH] Staging: goldfish: use __func__ instead of embedded function names
Embedded function names are less appropriate to use when
refactoring, can cause function renaming. Prefer the use
of "%s", __func__ to embedded function names
Signed-off-by: Mohsin Shan
---
drivers/staging/goldfish/goldfish_nand.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/staging/goldfish/goldfish_nand.c
b/drivers/staging/goldfish/goldfish_nand.c
index 76d60ee..8f92ff4 100644
--- a/drivers/staging/goldfish/goldfish_nand.c
+++ b/drivers/staging/goldfish/goldfish_nand.c
@@ -114,8 +114,8 @@ static int goldfish_nand_erase(struct mtd_info *mtd, struct
erase_info *instr)
len = len / mtd->writesize * (mtd->writesize + mtd->oobsize);
if (goldfish_nand_cmd(mtd, NAND_CMD_ERASE, ofs, len, NULL) != len) {
- pr_err("goldfish_nand_erase: erase failed, start %llx, len %x,
dev_size %llx, erase_size %x\n",
- ofs, len, mtd->size, mtd->erasesize);
+ pr_err("%s: erase failed, start %llx, len %x, dev_size %llx,
erase_size %x\n",
+ __func__, ofs, len, mtd->size, mtd->erasesize);
return -EIO;
}
@@ -125,8 +125,8 @@ static int goldfish_nand_erase(struct mtd_info *mtd, struct
erase_info *instr)
return 0;
invalid_arg:
- pr_err("goldfish_nand_erase: invalid erase, start %llx, len %x,
dev_size %llx, erase_size %x\n",
- ofs, len, mtd->size, mtd->erasesize);
+ pr_err("%s: invalid erase, start %llx, len %x, dev_size %llx,
erase_size %x\n",
+ __func__, ofs, len, mtd->size, mtd->erasesize);
return -EINVAL;
}
@@ -254,8 +254,8 @@ static int goldfish_nand_block_isbad(struct mtd_info *mtd,
loff_t ofs)
return goldfish_nand_cmd(mtd, NAND_CMD_BLOCK_BAD_GET, ofs, 0, NULL);
invalid_arg:
- pr_err("goldfish_nand_block_isbad: invalid arg, ofs %llx, dev_size
%llx, write_size %x\n",
- ofs, mtd->size, mtd->writesize);
+ pr_err("%s: invalid arg, ofs %llx, dev_size %llx, write_size %x\n",
+ __func__, ofs, mtd->size, mtd->writesize);
return -EINVAL;
}
@@ -277,8 +277,8 @@ static int goldfish_nand_block_markbad(struct mtd_info
*mtd, loff_t ofs)
return 0;
invalid_arg:
- pr_err("goldfish_nand_block_markbad: invalid arg, ofs %llx, dev_size
%llx, write_size %x\n",
- ofs, mtd->size, mtd->writesize);
+ pr_err("%s: invalid arg, ofs %llx, dev_size %llx, write_size %x\n",
+ __func__, ofs, mtd->size, mtd->writesize);
return -EINVAL;
}
--
2.7.4
Re: [PATCH v10 6/7] x86/arch_prctl: Add ARCH_[GET|SET]_CPUID
,"open list:KERNEL SELFTEST FRAMEWORK" ,kvm list From: h...@zytor.com Message-ID: On March 14, 2017 12:23:40 PM PDT, Andy Lutomirski wrote: >On Tue, Mar 14, 2017 at 12:01 PM, H. Peter Anvin wrote: >> and at least theoretically we >> could be indirecting though the ->stack pointer for every one if gcc >> can't tell it won't have changed (we really need to get thread_info >> moved into the task_struct allocation and away from the kernel stack, >> especially since on x86 the pointer is the same size as the vestigial >> structure it points to.) > >Solved by use of time machine: > >commit 15f4eae70d365bba26854c90b6002aaabb18c8aa >Author: Andy Lutomirski >Date: Tue Sep 13 14:29:25 2016 -0700 > >x86: Move thread_info into task_struct > > >:) My apologies, -ESTALEBRAINCACHE... -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
[RFC PATCH] rework memory hotplug onlining
Hi,
this is a follow up for [1]. In short the current semantic of the memory
hotplug is awkward and hard/impossible to use from the udev to online
memory as movable. The main problem is that only the last memblock or
the adjacent to highest movable memblock can be onlined as movable:
: Let's simulate memory hot online manually
: # echo 0x1 > /sys/devices/system/memory/probe
: # grep . /sys/devices/system/memory/memory32/valid_zones
: Normal Movable
:
: which looks reasonably right? Both Normal and Movable zones are allowed
:
: # echo $((0x1+(128<<20))) > /sys/devices/system/memory/probe
: # grep . /sys/devices/system/memory/memory3?/valid_zones
: /sys/devices/system/memory/memory32/valid_zones:Normal
: /sys/devices/system/memory/memory33/valid_zones:Normal Movable
:
: Huh, so our valid_zones have changed under our feet...
:
: # echo $((0x1+2*(128<<20))) > /sys/devices/system/memory/probe
: # grep . /sys/devices/system/memory/memory3?/valid_zones
: /sys/devices/system/memory/memory32/valid_zones:Normal
: /sys/devices/system/memory/memory33/valid_zones:Normal
: /sys/devices/system/memory/memory34/valid_zones:Normal Movable
:
: and again. So only the last memblock is considered movable. Let's try to
: online them now.
:
: # echo online_movable > /sys/devices/system/memory/memory34/state
: # grep . /sys/devices/system/memory/memory3?/valid_zones
: /sys/devices/system/memory/memory32/valid_zones:Normal
: /sys/devices/system/memory/memory33/valid_zones:Normal Movable
: /sys/devices/system/memory/memory34/valid_zones:Movable Normal
Now consider that the userspace gets the notification when the memblock
is added. If the udev context tries to online it it will a) race with
new memblocks showing up which leads to undeterministic behavior and
b) it will see memblocks ordered in growing physical addresses while
the only reliable way to online blocks as movable is exactly from other
directions. This is just plain wrong!
It seems that all this is just started by the semantic introduced by
9d99aaa31f59 ("[PATCH] x86_64: Support memory hotadd without sparsemem")
quite some time ago. When the movable onlinining has been introduced it
just built on top of this. It seems that the requirement to have
freshly probed memory associated with the zone normal is no longer
necessary. HOTPLUG depends on CONFIG_SPARSEMEM these days.
The following blob [2] simply removes all the zone specific operations
from __add_pages (aka arch_add_memory) path. Instead we do page->zone
association from move_pfn_range which is called from online_pages. The
criterion for movable/normal zone association is really simple now. We
just have to guarantee that zone Normal is always lower than zone
Movable. It would be actually sufficient to guarantee they do not
overlap and that is indeed trivial to implement now. I didn't do that
yet for simplicity of this change though.
I have lightly tested the patch and nothing really jumped at me. I
assume there will be some rough edges but it should be sufficient to
start the discussion at least. Please note the diffstat. We have added
a lot of code to tweak on top of the previous semantic which is just
sad. Instead of developing a robust solution the memory hotplug is full
of tweaks to satisfy particular usecase without longer term plans.
Please note that this is just for x86 now but I will address other
arches once there is an agreement this is the right approach.
Thoughts, objections?
[1] http://lkml.kernel.org/r/20170310135807.gi3...@dhcp22.suse.cz
[2] I didn't get to split it out to proper patches yet because I would
like to hear back about potential issues which would basically block the
whole thing before I spend more time on this
---
arch/x86/mm/init_32.c | 4 +-
arch/x86/mm/init_64.c | 9 +-
drivers/base/memory.c | 52 +++---
include/linux/memory_hotplug.h | 11 +-
include/linux/mmzone.h | 13 +-
mm/memory_hotplug.c| 360 +++--
mm/page_alloc.c| 11 +-
mm/sparse.c| 3 +-
8 files changed, 137 insertions(+), 326 deletions(-)
diff --git a/arch/x86/mm/init_32.c b/arch/x86/mm/init_32.c
index 928cfde76232..9deded3728bf 100644
--- a/arch/x86/mm/init_32.c
+++ b/arch/x86/mm/init_32.c
@@ -819,12 +819,10 @@ void __init mem_init(void)
int arch_add_memory(int nid, u64 start, u64 size, bool for_device)
{
struct pglist_data *pgdata = NODE_DATA(nid);
- struct zone *zone = pgdata->node_zones +
- zone_for_memory(nid, start, size, ZONE_HIGHMEM, for_device);
unsigned long start_pfn = start >> PAGE_SHIFT;
unsigned long nr_pages = size >> PAGE_SHIFT;
- return __add_pages(nid, zone, start_pfn, nr_pages);
+ return __add_pages(nid, start_pfn, nr_pages);
}
#ifdef CONFIG_MEMORY_HOTREMOVE
diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c
index 7eef17239378..bc53f24e6703 100644
--- a/arch/x86/mm/init_
Re: [PATCH v5 2/5] powerpc: kretprobes: override default function entry offset
On 2017/03/14 10:18AM, Arnaldo Carvalho de Melo wrote: > Em Thu, Mar 09, 2017 at 05:37:38PM +1100, Michael Ellerman escreveu: > > "Naveen N. Rao" writes: > > > On 2017/03/08 11:29AM, Arnaldo Carvalho de Melo wrote: > > >> > I wasn't sure if you were planning on picking up KPROBES_ON_FTRACE for > > >> > v4.11. If so, it would be good to take this patch through the powerpc > > >> > tree. Otherwise, this can go via Ingo's tree. > > >> > > >> If you guys convince Ingo that this should go _now_, then just cherry > > >> pick what was merged into tip/perf/core that is needed for the arch > > >> specific stuff and go from there. > > > > > > Ok, in hindsight, I think Michael's concern was actually for v4.12 > > > > Yes I was talking about 4.12, sorry I thought that was implied :) > > > > > itself, in which case this particular patch can go via powerpc tree, > > > while the rest of the patches in this series can go via your tree. > > > > > > Michael? > > > > Yeah I think that's the easiest option. The function will be temporarily > > unused until the two trees are merged, but I think that's fine. > > Ok, done that, now compile testing building it in my > multi-distro/x-build containers. Thanks, Arnaldo! I did however notice that you don't seem to have applied Patch 1/5 from this series: https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1347858.html That patch is needed to ensure perf continues to work when ftrace README advertises support for ref_reloc_sym+offset for kretprobes. Can you please apply that as well? - Naveen
Re: [PATCH 1/3] kvm: arm/arm64: Take mmap_sem in stage2_unmap_vm
On Tue, Mar 14, 2017 at 02:52:32PM +, Suzuki K Poulose wrote:
> From: Marc Zyngier
>
> We don't hold the mmap_sem while searching for the VMAs when
> we try to unmap each memslot for a VM. Fix this properly to
> avoid unexpected results.
>
> Fixes: commit 957db105c997 ("arm/arm64: KVM: Introduce stage2_unmap_vm")
> Cc: sta...@vger.kernel.org # v3.19+
> Cc: Christoffer Dall
> Signed-off-by: Marc Zyngier
> Signed-off-by: Suzuki K Poulose
> ---
> arch/arm/kvm/mmu.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c
> index 962616f..f2e2e0c 100644
> --- a/arch/arm/kvm/mmu.c
> +++ b/arch/arm/kvm/mmu.c
> @@ -803,6 +803,7 @@ void stage2_unmap_vm(struct kvm *kvm)
> int idx;
>
> idx = srcu_read_lock(&kvm->srcu);
> + down_read(¤t->mm->mmap_sem);
> spin_lock(&kvm->mmu_lock);
>
> slots = kvm_memslots(kvm);
> @@ -810,6 +811,7 @@ void stage2_unmap_vm(struct kvm *kvm)
> stage2_unmap_memslot(kvm, memslot);
>
> spin_unlock(&kvm->mmu_lock);
> + up_read(¤t->mm->mmap_sem);
> srcu_read_unlock(&kvm->srcu, idx);
> }
>
> --
> 2.7.4
>
Are we sure that holding mmu_lock is valid while holding the mmap_sem?
Thanks,
-Christoffer
Re: [RFC PATCH] ASoC: wm8960: Use physical width for bclk
On Tue, Mar 14, 2017 at 06:57:02PM +0200, Daniel Baluta wrote: > bclk is derived from sysclk with the help of bclk_divs. Anyhow, for > S20_3LE format there is no bclk_divs that could be used to derive > an exact bclk. > > We can fix this by using storage size instead the exact > number of bits of the sample when computing bclk. > > With this approach we can play S20_3LE encoded files at the cost of > some unused BCLK cycles for S20_3LE and S24_LE. > > Signed-off-by: Daniel Baluta > --- > sound/soc/codecs/wm8960.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/sound/soc/codecs/wm8960.c b/sound/soc/codecs/wm8960.c > index e1429e3..18ca5fc 100644 > --- a/sound/soc/codecs/wm8960.c > +++ b/sound/soc/codecs/wm8960.c > @@ -722,7 +722,8 @@ static int wm8960_hw_params(struct snd_pcm_substream > *substream, > bool tx = substream->stream == SNDRV_PCM_STREAM_PLAYBACK; > int i; > > - wm8960->bclk = snd_soc_params_to_bclk(params); > + wm8960->bclk = params_physical_width(params) * > + params_channels(params) * params_rate(params); > if (params_channels(params) == 1) > wm8960->bclk *= 2; Would quite like to see Mark's thoughts on this. Feels a bit to me (although I am not certain) like we are solving the problem in the wrong place, isn't this really setting the desired BCLK and then in wm8960_configure_clocking we should set the lowest BCLK we can that is greater than or equal to the desired. Thanks, Charles
Re: [PATCH v3 2/3] gpio: wm831x: Add basic device tree support
On Mon, Mar 6, 2017 at 5:46 PM, Charles Keepax wrote: > Now the wm831x-core has basic DT support we can update this driver to > allow use of the GPIOs within a device tree system. > > Signed-off-by: Charles Keepax > Acked-by: Linus Walleij Patch applied. Yours, Linus Walleij
Re: [PATCH 3/3] kvm: arm/arm64: Fix locking for kvm_free_stage2_pgd
On Tue, Mar 14, 2017 at 02:52:34PM +, Suzuki K Poulose wrote:
> In kvm_free_stage2_pgd() we don't hold the kvm->mmu_lock while calling
> unmap_stage2_range() on the entire memory range for the guest. This could
> cause problems with other callers (e.g, munmap on a memslot) trying to
> unmap a range.
>
> Fixes: commit d5d8184d35c9 ("KVM: ARM: Memory virtualization setup")
> Cc: sta...@vger.kernel.org # v3.10+
> Cc: Marc Zyngier
> Cc: Christoffer Dall
> Signed-off-by: Suzuki K Poulose
> ---
> arch/arm/kvm/mmu.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c
> index 13b9c1f..b361f71 100644
> --- a/arch/arm/kvm/mmu.c
> +++ b/arch/arm/kvm/mmu.c
> @@ -831,7 +831,10 @@ void kvm_free_stage2_pgd(struct kvm *kvm)
> if (kvm->arch.pgd == NULL)
> return;
>
> + spin_lock(&kvm->mmu_lock);
> unmap_stage2_range(kvm, 0, KVM_PHYS_SIZE);
> + spin_unlock(&kvm->mmu_lock);
> +
This ends up holding the spin lock for potentially quite a while, where
we can do things like __flush_dcache_area(), which I think can fault.
Is that valid?
Thanks,
-Christoffer
> /* Free the HW pgd, one page at a time */
> free_pages_exact(kvm->arch.pgd, S2_PGD_SIZE);
> kvm->arch.pgd = NULL;
> --
> 2.7.4
>
Re: [PATCH 0/6] x86: 5-level paging enabling for v4.12, Part 1
On Tue 14-03-17 08:47:29, Ingo Molnar wrote: > > * Kirill A. Shutemov wrote: > > > Here's the first bunch of patches of 5-level patchset. Let's see if I'm on > > right track addressing Ingo's feedback. :) > > > > These patches prepare x86 code to be switched from > > > > to . It's a stepping stone for adding 5-level > > paging support. > > > > Please review and consider applying. > > > > Kirill A. Shutemov (6): > > x86/mm: Extend headers with basic definitions to support 5-level > > paging > > x86/mm: Convert trivial cases of page table walk to 5-level paging > > x86/gup: Add 5-level paging support > > x86/ident_map: Add 5-level paging support > > x86/vmalloc: Add 5-level paging support > > x86/power: Add 5-level paging support > > > > arch/x86/include/asm/pgtable-2level_types.h | 1 + > > arch/x86/include/asm/pgtable-3level_types.h | 1 + > > arch/x86/include/asm/pgtable.h | 26 +--- > > arch/x86/include/asm/pgtable_64_types.h | 1 + > > arch/x86/include/asm/pgtable_types.h| 30 - > > arch/x86/kernel/tboot.c | 6 ++- > > arch/x86/kernel/vm86_32.c | 6 ++- > > arch/x86/mm/fault.c | 66 > > + > > arch/x86/mm/gup.c | 33 --- > > arch/x86/mm/ident_map.c | 51 +++--- > > arch/x86/mm/init_32.c | 22 +++--- > > arch/x86/mm/ioremap.c | 3 +- > > arch/x86/mm/pgtable.c | 4 +- > > arch/x86/mm/pgtable_32.c| 8 +++- > > arch/x86/platform/efi/efi_64.c | 13 -- > > arch/x86/power/hibernate_32.c | 7 ++- > > arch/x86/power/hibernate_64.c | 50 -- > > 17 files changed, 269 insertions(+), 59 deletions(-) > > Much better! > > I've applied them, with (very) minor readability edits here and there, and > will > push them out into tip:x86/mm and tip:master after some testing - you can use > that > as a base for the remaining submissions. JFYI, I have cherry picked these and those merged via Linus tree into the mmotm git tree [1] (tag mmotm-2017-03-14-15-41) [1] git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git -- Michal Hocko SUSE Labs
[PATCH] clk: stm32h7: Add stm32h743 clock driver
From: Gabriel Fernandez
This patch enables clocks for STM32H743 boards.
Signed-off-by: Gabriel Fernandez
---
.../devicetree/bindings/clock/st,stm32h7-rcc.txt | 152 ++
drivers/clk/Makefile |1 +
drivers/clk/clk-stm32h7.c | 1586
include/dt-bindings/clock/stm32h7-clks.h | 165 ++
include/dt-bindings/mfd/stm32h7-rcc.h | 138 ++
5 files changed, 2042 insertions(+)
create mode 100644 Documentation/devicetree/bindings/clock/st,stm32h7-rcc.txt
create mode 100644 drivers/clk/clk-stm32h7.c
create mode 100644 include/dt-bindings/clock/stm32h7-clks.h
create mode 100644 include/dt-bindings/mfd/stm32h7-rcc.h
diff --git a/Documentation/devicetree/bindings/clock/st,stm32h7-rcc.txt
b/Documentation/devicetree/bindings/clock/st,stm32h7-rcc.txt
new file mode 100644
index 000..9d4b587
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/st,stm32h7-rcc.txt
@@ -0,0 +1,152 @@
+STMicroelectronics STM32H7 Reset and Clock Controller
+=
+
+The RCC IP is both a reset and a clock controller.
+
+Please refer to clock-bindings.txt for common clock controller binding usage.
+Please also refer to reset.txt for common reset controller binding usage.
+
+Required properties:
+- compatible: Should be:
+ "st,stm32h743-rcc"
+
+- reg: should be register base and length as documented in the
+ datasheet
+
+- #reset-cells: 1, see below
+
+- #clock-cells : from common clock binding; shall be set to 1
+
+- clocks: External oscillator clock phandle
+ - high speed external clock signal (HSE)
+ - low speed external clock signal (LSE)
+ - external I2S clock (I2S_CKIN)
+
+- st,syscfg: phandle for pwrcfg, mandatory to disable/enable backup domain
+ write protection (RTC clock).
+
+- pll x node: Allow to register a pll with specific parameters.
+ Please see PLL section below.
+
+Example:
+
+ rcc: rcc@58024400 {
+ #reset-cells = <1>;
+ #clock-cells = <2>
+ compatible = "st,stm32h743-rcc", "st,stm32-rcc";
+ reg = <0x58024400 0x400>;
+ clocks = <&clk_hse>, <&clk_lse>, <&clk_i2s_ckin>;
+
+ st,syscfg = <&pwrcfg>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ vco1@58024430 {
+ #clock-cells = <0>;
+ compatible = "stm32,pll";
+ reg = <0>;
+ };
+
+ vco2@58024438 {
+ #clock-cells = <0>;
+ compatible = "stm32,pll";
+ reg = <1>;
+ st,clock-div = <2>;
+ st,clock-mult = <40>;
+ st,frac-status = <0>;
+ st,frac = <0>;
+ st,vcosel = <1>;
+ st,pllrge = <2>;
+ };
+ };
+
+
+STM32H7 PLL
+---
+
+The VCO of STM32 PLL could be reprensented like this:
+
+ Vref-
+>| / DIVM |>| x DIVN | --> VCO
+ -
+^
+|
+ ---
+| FRACN |
+ ---
+
+When the PLL is configured in integer mode:
+- VCO = ( Vref / DIVM ) * DIVN
+
+When the PLL is configured in fractional mode:
+- VCO = ( Vref / DIVM ) * ( DIVN + FRACN / 2^13)
+
+
+Required properties for pll node:
+- compatible: Should be:
+ "stm32,pll"
+
+- #clock-cells: from common clock binding; shall be set to 0
+- reg: Should be the pll number.
+
+Optional properties:
+- st,clock-div: DIVM division factor : <1..63>
+- st,clock-mult: DIVN multiplication factor : <4..512>
+
+- st,frac-status:
+ - 0 Pll is configured in integer mode
+ - 1 Pll is configure in fractional mode
+
+- st,frac: Fractional part of the multiplication factor : <0..8191>
+
+- st,vcosel: VCO selection
+ - 0: Wide VCO range:192 to 836 MHz
+ - 1: Medium VCO range:150 to 420 MHz
+
+- st,pllrge: PLL input frequency range
+ - 0: The PLL input (Vref / DIVM) clock range frequency is between 1 and 2 MHz
+ - 1: The PLL input (Vref / DIVM) clock range frequency is between 2 and 4 MHz
+ - 2: The PLL input (Vref / DIVM) clock range frequency is between 4 and 8 MHz
+ - 3: The PLL input (Vref / DIVM) clock range frequency is between 8 and 16
MHz
+
+
+The peripheral clock consumer should specify the desired clock by
+having the clock ID in its "clocks" phandle cell.
+
+All available clocks are defined as preprocessor macros in
+dt-bindings/clock/stm32h7-clks.h header and can be used in device
+tree sources.
+
+Example:
+
+ timer5: timer@4c00 {
+ compatible = "st,stm32-timer";
+ reg = <0x4c00 0x400>;
+ interrupts = <50>;
+ clocks
Re: [PATCH 1/4] cdc-acm: reassemble fragmented notifications
Am Dienstag, den 14.03.2017, 21:14 +0100 schrieb Tobias Herzog:
> USB devices may have very limitited endpoint packet sizes, so that
> notifications can not be transferred within one single usb packet.
> Reassembling of multiple packages may be necessary.
Hi,
thank you for the patch. Unfortunately it has some issue.
Please see the comments inside.
Regards
Oliver
>
> Signed-off-by: Tobias Herzog
> ---
> drivers/usb/class/cdc-acm.c | 102
> +++-
> drivers/usb/class/cdc-acm.h | 2 +
> 2 files changed, 75 insertions(+), 29 deletions(-)
>
> diff --git a/drivers/usb/class/cdc-acm.c b/drivers/usb/class/cdc-acm.c
> index e35b150..40714fe 100644
> --- a/drivers/usb/class/cdc-acm.c
> +++ b/drivers/usb/class/cdc-acm.c
> @@ -282,39 +282,13 @@ static DEVICE_ATTR(iCountryCodeRelDate, S_IRUGO,
> show_country_rel_date, NULL);
> * Interrupt handlers for various ACM device responses
> */
>
> -/* control interface reports status changes with "interrupt" transfers */
> -static void acm_ctrl_irq(struct urb *urb)
> +static void acm_process_notification(struct acm *acm, unsigned char *buf)
> {
> - struct acm *acm = urb->context;
> - struct usb_cdc_notification *dr = urb->transfer_buffer;
> - unsigned char *data;
> int newctrl;
> int difference;
> - int retval;
> - int status = urb->status;
> + struct usb_cdc_notification *dr = (struct usb_cdc_notification *)buf;
> + unsigned char *data = (unsigned char *)(dr + 1);
>
> - switch (status) {
> - case 0:
> - /* success */
> - break;
> - case -ECONNRESET:
> - case -ENOENT:
> - case -ESHUTDOWN:
> - /* this urb is terminated, clean up */
> - dev_dbg(&acm->control->dev,
> - "%s - urb shutting down with status: %d\n",
> - __func__, status);
> - return;
> - default:
> - dev_dbg(&acm->control->dev,
> - "%s - nonzero urb status received: %d\n",
> - __func__, status);
> - goto exit;
> - }
> -
> - usb_mark_last_busy(acm->dev);
> -
> - data = (unsigned char *)(dr + 1);
> switch (dr->bNotificationType) {
> case USB_CDC_NOTIFY_NETWORK_CONNECTION:
> dev_dbg(&acm->control->dev,
> @@ -363,8 +337,74 @@ static void acm_ctrl_irq(struct urb *urb)
> __func__,
> dr->bNotificationType, dr->wIndex,
> dr->wLength, data[0], data[1]);
> + }
> +}
> +
> +/* control interface reports status changes with "interrupt" transfers */
> +static void acm_ctrl_irq(struct urb *urb)
> +{
> + struct acm *acm = urb->context;
> + struct usb_cdc_notification *dr = urb->transfer_buffer;
> + unsigned int current_size = urb->actual_length;
> + unsigned int expected_size, copy_size;
> + int retval;
> + int status = urb->status;
> +
> + switch (status) {
> + case 0:
> + /* success */
> break;
> + case -ECONNRESET:
> + case -ENOENT:
> + case -ESHUTDOWN:
> + /* this urb is terminated, clean up */
> + kfree(acm->notification_buffer);
> + acm->notification_buffer = NULL;
Why? Disconnect() will free it anyway. It should be enough
to discard the content.
> + dev_dbg(&acm->control->dev,
> + "%s - urb shutting down with status: %d\n",
> + __func__, status);
> + return;
> + default:
> + dev_dbg(&acm->control->dev,
> + "%s - nonzero urb status received: %d\n",
> + __func__, status);
> + goto exit;
> }
> +
> + usb_mark_last_busy(acm->dev);
> +
> + if (acm->notification_buffer)
> + dr = (struct usb_cdc_notification *)acm->notification_buffer;
> +
> + /* assume the first package contains at least two bytes */
> + expected_size = dr->wLength + 8;
You need the explain where you got the 8 from. In fact a define would
be best.
> +
> + if (current_size < expected_size) {
> + /* notification is transmitted framented, reassemble */
Please fix the typo.
> + if (!acm->notification_buffer) {
> + acm->notification_buffer =
> + kmalloc(expected_size, GFP_ATOMIC);
This can fail. You _must_ check for that.
> + acm->nb_index = 0;
> + }
> +
> + copy_size = min(current_size,
> + expected_size - acm->nb_index);
> +
> + memcpy(&acm->notification_buffer[acm->nb_index],
> +urb->transfer_buffer, copy_size);
> + acm->nb_index += copy_size;
> + current_size = acm->nb_index;
> + }
> +
> + if (current_size < expected_size)
> + goto exit;
This is an unneed
Re: [PATCH 2/4] cdc-acm: fix possible invalid access when processing notification
Am Dienstag, den 14.03.2017, 21:14 +0100 schrieb Tobias Herzog:
> Notifications may only be 8 bytes so long. Accessing the 9th and
> 10th byte of unimplemented/unknown notifications may be insecure.
> Also check the length of known notifications before accessing anything
> behind the 8th byte.
>
> Signed-off-by: Tobias Herzog
> ---
> drivers/usb/class/cdc-acm.c | 11 ---
> 1 file changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/usb/class/cdc-acm.c b/drivers/usb/class/cdc-acm.c
> index 40714fe..b99127e 100644
> --- a/drivers/usb/class/cdc-acm.c
> +++ b/drivers/usb/class/cdc-acm.c
> @@ -296,6 +296,12 @@ static void acm_process_notification(struct acm *acm,
> unsigned char *buf)
> break;
>
> case USB_CDC_NOTIFY_SERIAL_STATE:
> + if (dr->wLength != 2) {
Endianness
> + dev_dbg(&acm->control->dev,
> + "%s - malformed serial state\n", __func__);
> + break;
> + }
> +
> newctrl = get_unaligned_le16(data);
>
> if (!acm->clocal && (acm->ctrlin & ~newctrl & ACM_CTRL_DCD)) {
> @@ -332,11 +338,10 @@ static void acm_process_notification(struct acm *acm,
> unsigned char *buf)
>
> default:
> dev_dbg(&acm->control->dev,
> - "%s - unknown notification %d received: index %d "
> - "len %d data0 %d data1 %d\n",
> + "%s - unknown notification %d received: index %d len
> %d\n",
> __func__,
> dr->bNotificationType, dr->wIndex,
> - dr->wLength, data[0], data[1]);
> + dr->wLength);
> }
> }
>
Re: [PATCH 4/4] drm/amdgpu: resize VRAM BAR for CPU access
Yes, exactly that.
Christian.
Am 15.03.2017 um 09:25 schrieb Zhou, David(ChunMing):
Does that means we don't need invisible vram later?
David
-Original Message-
From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
Christian K?nig
Sent: Wednesday, March 15, 2017 3:38 PM
To: Ayyappa Ch
Cc: linux-...@vger.kernel.org; linux-kernel@vger.kernel.org;
amd-...@lists.freedesktop.org; platform-driver-...@vger.kernel.org;
helg...@kernel.org; dri-de...@lists.freedesktop.org
Subject: Re: [PATCH 4/4] drm/amdgpu: resize VRAM BAR for CPU access
Carizzo is an APU and resizing BARs isn't needed nor supported there.
The CPU can access the full stolen VRAM directly on that hardware.
As far as I know ASICs with support for this are Tonga, Fiji and all Polaris
variants.
Christian.
Am 15.03.2017 um 08:23 schrieb Ayyappa Ch:
Is it possible on Carrizo asics? Or only supports on newer asics?
On Mon, Mar 13, 2017 at 6:11 PM, Christian König
wrote:
From: Christian König
Try to resize BAR0 to let CPU access all of VRAM.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h| 1 +
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 29 +
drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c | 8 +---
drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c | 8 +---
4 files changed, 40 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index 3b81ded..905ded9 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -1719,6 +1719,7 @@ uint64_t amdgpu_ttm_tt_pte_flags(struct amdgpu_device
*adev, struct ttm_tt *ttm,
struct ttm_mem_reg *mem);
void amdgpu_vram_location(struct amdgpu_device *adev, struct amdgpu_mc *mc,
u64 base);
void amdgpu_gtt_location(struct amdgpu_device *adev, struct
amdgpu_mc *mc);
+void amdgpu_resize_bar0(struct amdgpu_device *adev);
void amdgpu_ttm_set_active_vram_size(struct amdgpu_device *adev, u64 size);
int amdgpu_ttm_init(struct amdgpu_device *adev);
void amdgpu_ttm_fini(struct amdgpu_device *adev); diff --git
a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index 118f4e6..92955fe 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -692,6 +692,35 @@ void amdgpu_gtt_location(struct amdgpu_device *adev,
struct amdgpu_mc *mc)
mc->gtt_size >> 20, mc->gtt_start, mc->gtt_end);
}
+/**
+ * amdgpu_resize_bar0 - try to resize BAR0
+ *
+ * @adev: amdgpu_device pointer
+ *
+ * Try to resize BAR0 to make all VRAM CPU accessible.
+ */
+void amdgpu_resize_bar0(struct amdgpu_device *adev) {
+ u32 size = max(ilog2(adev->mc.real_vram_size - 1) + 1, 20) - 20;
+ int r;
+
+ r = pci_resize_resource(adev->pdev, 0, size);
+
+ if (r == -ENOTSUPP) {
+ /* The hardware don't support the extension. */
+ return;
+
+ } else if (r == -ENOSPC) {
+ DRM_INFO("Not enoigh PCI address space for a large BAR.");
+ } else if (r) {
+ DRM_ERROR("Problem resizing BAR0 (%d).", r);
+ }
+
+ /* Reinit the doorbell mapping, it is most likely moved as well */
+ amdgpu_doorbell_fini(adev);
+ BUG_ON(amdgpu_doorbell_init(adev));
+}
+
/*
* GPU helpers function.
*/
diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
b/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
index dc9b6d6..36a7aa5 100644
--- a/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
@@ -367,13 +367,15 @@ static int gmc_v7_0_mc_init(struct amdgpu_device *adev)
break;
}
adev->mc.vram_width = numchan * chansize;
- /* Could aper size report 0 ? */
- adev->mc.aper_base = pci_resource_start(adev->pdev, 0);
- adev->mc.aper_size = pci_resource_len(adev->pdev, 0);
/* size in MB on si */
adev->mc.mc_vram_size = RREG32(mmCONFIG_MEMSIZE) * 1024ULL * 1024ULL;
adev->mc.real_vram_size = RREG32(mmCONFIG_MEMSIZE) * 1024ULL
* 1024ULL;
+ if (!(adev->flags & AMD_IS_APU))
+ amdgpu_resize_bar0(adev);
+ adev->mc.aper_base = pci_resource_start(adev->pdev, 0);
+ adev->mc.aper_size = pci_resource_len(adev->pdev, 0);
+
#ifdef CONFIG_X86_64
if (adev->flags & AMD_IS_APU) {
adev->mc.aper_base =
((u64)RREG32(mmMC_VM_FB_OFFSET)) << 22; diff --git
a/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
b/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
index c087b00..7761ad3 100644
--- a/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
@@ -459,13 +459,15 @@ static int gmc_v8_0_mc_init(struct amdgpu_device *adev)
break;
}
adev->mc.vram_width = numchan * chansize;
- /* Could aper size report 0 ? */
- adev->mc.aper
Re: [PATCH v2 16/23] MAINTAINERS: Add file patterns for powerpc device tree bindings
Geert Uytterhoeven writes:
> On Wed, Mar 15, 2017 at 1:19 AM, Michael Ellerman wrote:
>> Geert Uytterhoeven writes:
>>> Submitters of device tree binding documentation may forget to CC
>>> the subsystem maintainer if this is missing.
>>>
>>> Signed-off-by: Geert Uytterhoeven
>>> Cc: Benjamin Herrenschmidt
>>> Cc: Paul Mackerras
>>> Cc: Michael Ellerman
>>> Cc: linuxppc-...@lists.ozlabs.org
>>> ---
>>> Please apply this patch directly if you want to be involved in device
>>> tree binding documentation for your subsystem.
>>>
>>> v2:
>>> - Rebased on top of commit a42715830d552d7c ("MAINTAINERS: Remove
>>> powerpc's "opal" pattern match), which just added "powerpc/opal",
>>> while obviously the whole "powerpc" hierarchy is of interest.
>>>
>>> Impact on next-20170310:
>>
>> Actual diff ignoring ordering etc:
>>
>> +Benjamin Herrenschmidt (supporter:LINUX FOR
>> POWERPC (32-BIT AND 64-BIT))
>> +Paul Mackerras (supporter:LINUX FOR POWERPC (32-BIT AND
>> 64-BIT))
>> +linuxppc-...@lists.ozlabs.org (open list:LINUX FOR POWERPC (32-BIT AND
>> 64-BIT))
>> -Scott Wood (commit_signer:5/11=45%)
>> -Zhao Qiang (commit_signer:4/11=36%,authored:4/11=36%)
>> -Christian Lamparter (commit_signer:1/11=9%)
>> -yangbo lu (authored:1/11=9%)
>> -"Otto Kekäläinen" (authored:1/11=9%)
>> -Chris Packham (authored:1/11=9%)
>> -York Sun (authored:1/11=9%)
>>
>> Which looks bad as all the NXP folks get dropped, but they should be
>> reading linuxppc-dev. So I think I'll merge this, unless anyone
>> disagrees.
>
> They got dropped because in the absence of a maintainer entry, the
> last committers are listed. If they need to be listed, I can send patches to
> add
> more specific entries for 4xx and fsl DT bindings, like:
This is one is probably worth doing:
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 0f1c2f96c99aa936..40b392a4f399adbe 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -5266,6 +5266,7 @@ M:Scott Wood
> L: linuxppc-...@lists.ozlabs.org
> L: linux-arm-ker...@lists.infradead.org
> S: Maintained
> +F: Documentation/devicetree/bindings/powerpc/fsl/
> F: drivers/soc/fsl/
> F: include/linux/fsl/
I'll fold it in before applying?
But I wouldn't bother with 4xx, just falling back to linuxppc-dev is
fine for that.
> @@ -7540,6 +7541,7 @@ M:Matt Porter
> W: http://www.penguinppc.org/
> L: linuxppc-...@lists.ozlabs.org
> S: Maintained
> +F: Documentation/devicetree/bindings/powerpc/4xx/
> F: arch/powerpc/platforms/40x/
> F: arch/powerpc/platforms/44x/
cheers
[PATCH] arm64: dts: rockchip: rk3368 swap clust0 and clust1
Before this patch, clust1 has little core0~3, clust0 has big core0~3
cpu_l | cpu0 |
cpu_l | cpu1 | clust1
cpu_l | cpu2 |
cpu_l | cpu3 |
--
cpu_b | cpu4 |
cpu_b | cpu5 | clust0
cpu_b | cpu6 |
cpu_b | cpu7 |
With this patch, clust0 will have little core0~3, clust1 will have big core0~3
cpu_l | cpu0 |
cpu_l | cpu1 | clust0
cpu_l | cpu2 |
cpu_l | cpu3 |
--
cpu_b | cpu4 |
cpu_b | cpu5 | clust1
cpu_b | cpu6 |
cpu_b | cpu7 |
It makes no other change, just keep same with other SoCs definations.
Signed-off-by: Jianqun Xu
---
arch/arm64/boot/dts/rockchip/rk3368.dtsi | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3368.dtsi
b/arch/arm64/boot/dts/rockchip/rk3368.dtsi
index a635adc..7b9d1e6 100644
--- a/arch/arm64/boot/dts/rockchip/rk3368.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3368.dtsi
@@ -79,31 +79,31 @@
cpu-map {
cluster0 {
core0 {
- cpu = <&cpu_b0>;
+ cpu = <&cpu_l0>;
};
core1 {
- cpu = <&cpu_b1>;
+ cpu = <&cpu_l1>;
};
core2 {
- cpu = <&cpu_b2>;
+ cpu = <&cpu_l2>;
};
core3 {
- cpu = <&cpu_b3>;
+ cpu = <&cpu_l3>;
};
};
cluster1 {
core0 {
- cpu = <&cpu_l0>;
+ cpu = <&cpu_b0>;
};
core1 {
- cpu = <&cpu_l1>;
+ cpu = <&cpu_b1>;
};
core2 {
- cpu = <&cpu_l2>;
+ cpu = <&cpu_b2>;
};
core3 {
- cpu = <&cpu_l3>;
+ cpu = <&cpu_b3>;
};
};
};
--
1.9.1
Re: [PATCH 1/2] gpio: mmio: add support for NI 169445 NAND GPIO
On Mon, Mar 6, 2017 at 9:06 PM, Nathan Sullivan wrote: > The GPIO-based NAND controller on National Instruments 169445 hardware > exposes a set of simple lines for the control signals. > > Signed-off-by: Nathan Sullivan Totally standard ans simple patch, applied. Hint: it's probably nice to use the gpio-line-names attribute on these boards to name the lines. Yours, Linus Walleij
Re: [Outreachy kernel] Re: [PATCH 0/2] Improve code readability
On Wed, 15 Mar 2017, Arushi Singhal wrote:
> HiThis Patch series is not yet added to the kernel tree.
The normal process is to send it again, with RESEND inside the [PATCH]
box.
julia
> Thanks
> Arushi
>
> On Saturday, 11 March 2017 02:12:02 UTC+5:30, Arushi Singhal wrote:
> Improve readability by fixing multiple checkpatch.pl
> issues.
>
> Arushi Singhal (2):
> staging: speakup: Avoid multiple assignments on same line
> staging: speakup: fixes braces {} should be used on all arms
> of this
> statement
>
> drivers/staging/speakup/main.c | 6 --
> drivers/staging/speakup/speakup_decext.c | 6 +++---
> drivers/staging/speakup/speakup_decpc.c | 6 +++---
> drivers/staging/speakup/speakup_dectlk.c | 6 +++---
> drivers/staging/speakup/varhandlers.c | 12 +++-
> 5 files changed, 20 insertions(+), 16 deletions(-)
>
> --
> 2.11.0
>
> --
> You received this message because you are subscribed to the Google Groups
> "outreachy-kernel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to outreachy-kernel+unsubscr...@googlegroups.com.
> To post to this group, send email to outreachy-ker...@googlegroups.com.
> To view this discussion on the web
> visithttps://groups.google.com/d/msgid/outreachy-kernel/e3451e76-4119-4ea9-8bd0-
> 134de6504fd0%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
>
Re: [PATCH 1/3] kvm: arm/arm64: Take mmap_sem in stage2_unmap_vm
On 15/03/17 09:17, Christoffer Dall wrote:
> On Tue, Mar 14, 2017 at 02:52:32PM +, Suzuki K Poulose wrote:
>> From: Marc Zyngier
>>
>> We don't hold the mmap_sem while searching for the VMAs when
>> we try to unmap each memslot for a VM. Fix this properly to
>> avoid unexpected results.
>>
>> Fixes: commit 957db105c997 ("arm/arm64: KVM: Introduce stage2_unmap_vm")
>> Cc: sta...@vger.kernel.org # v3.19+
>> Cc: Christoffer Dall
>> Signed-off-by: Marc Zyngier
>> Signed-off-by: Suzuki K Poulose
>> ---
>> arch/arm/kvm/mmu.c | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>> diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c
>> index 962616f..f2e2e0c 100644
>> --- a/arch/arm/kvm/mmu.c
>> +++ b/arch/arm/kvm/mmu.c
>> @@ -803,6 +803,7 @@ void stage2_unmap_vm(struct kvm *kvm)
>> int idx;
>>
>> idx = srcu_read_lock(&kvm->srcu);
>> +down_read(¤t->mm->mmap_sem);
>> spin_lock(&kvm->mmu_lock);
>>
>> slots = kvm_memslots(kvm);
>> @@ -810,6 +811,7 @@ void stage2_unmap_vm(struct kvm *kvm)
>> stage2_unmap_memslot(kvm, memslot);
>>
>> spin_unlock(&kvm->mmu_lock);
>> +up_read(¤t->mm->mmap_sem);
>> srcu_read_unlock(&kvm->srcu, idx);
>> }
>>
>> --
>> 2.7.4
>>
>
> Are we sure that holding mmu_lock is valid while holding the mmap_sem?
Maybe I'm just confused by the many levels of locking, Here's my rational:
- kvm->srcu protects the memslot list
- mmap_sem protects the kernel VMA list
- mmu_lock protects the stage2 page tables (at least here)
I don't immediately see any issue with holding the mmap_sem mutex here
(unless there is a path that would retrigger a down operation on the
mmap_sem?).
Or am I missing something obvious?
Thanks,
M.
--
Jazz is not dead. It just smells funny...
Re: [PATCH 2/2] MIPS: NI 169445 board support
On Mon, Mar 6, 2017 at 9:06 PM, Nathan Sullivan wrote:
> Support the National Instruments 169445 board.
>
> Signed-off-by: Nathan Sullivan
(...)
> + gpio1:gpio-controller@1f300010 {
> + compatible = "ni,169445-nand-gpio";
> + reg = <0x10 0x4>;
> + reg-names = "dat";
> + gpio-controller;
> + #gpio-cells = <2>;
> + ngpios = <5>;
Here I would add:
gpio-line-names = "NC", "NCE", "ALE", "CLE", "NWP";
(Dunno about the first one, maybe you have a schematic?)
> + };
> +
> + gpio2:gpio-controller@1f300014 {
> + compatible = "ni,169445-nand-gpio";
> + reg = <0x14 0x4>;
> + reg-names = "dat";
> + gpio-controller;
> + #gpio-cells = <2>;
> + ngpios = <1>;
gpio-line-names = "RDY";
> + };
> +
> + nand@1f30 {
> + compatible = "gpio-control-nand";
> + nand-on-flash-bbt;
> + nand-ecc-mode = "soft_bch";
> + nand-ecc-step-size = <512>;
> + nand-ecc-strength = <4>;
> + reg = <0x0 4>;
> + gpios = <&gpio2 0 0>, /* rdy */
> + <&gpio1 1 0>, /* nce */
> + <&gpio1 2 0>, /* ale */
> + <&gpio1 3 0>, /* cle */
> + <&gpio1 4 0>; /* nwp */
> + };
To reflect this. "lsgpio" gives better info after that.
Other than that:
Acked-by: Linus Walleij
Yours,
Linus Walleij
Re: [PATCH v2 16/23] MAINTAINERS: Add file patterns for powerpc device tree bindings
Hi Michael,
On Wed, Mar 15, 2017 at 10:30 AM, Michael Ellerman wrote:
> Geert Uytterhoeven writes:
>> On Wed, Mar 15, 2017 at 1:19 AM, Michael Ellerman
>> wrote:
>>> Geert Uytterhoeven writes:
Submitters of device tree binding documentation may forget to CC
the subsystem maintainer if this is missing.
Signed-off-by: Geert Uytterhoeven
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Michael Ellerman
Cc: linuxppc-...@lists.ozlabs.org
---
Please apply this patch directly if you want to be involved in device
tree binding documentation for your subsystem.
v2:
- Rebased on top of commit a42715830d552d7c ("MAINTAINERS: Remove
powerpc's "opal" pattern match), which just added "powerpc/opal",
while obviously the whole "powerpc" hierarchy is of interest.
Impact on next-20170310:
>>>
>>> Actual diff ignoring ordering etc:
>>>
>>> +Benjamin Herrenschmidt (supporter:LINUX FOR
>>> POWERPC (32-BIT AND 64-BIT))
>>> +Paul Mackerras (supporter:LINUX FOR POWERPC (32-BIT
>>> AND 64-BIT))
>>> +linuxppc-...@lists.ozlabs.org (open list:LINUX FOR POWERPC (32-BIT AND
>>> 64-BIT))
>>> -Scott Wood (commit_signer:5/11=45%)
>>> -Zhao Qiang (commit_signer:4/11=36%,authored:4/11=36%)
>>> -Christian Lamparter (commit_signer:1/11=9%)
>>> -yangbo lu (authored:1/11=9%)
>>> -"Otto Kekäläinen" (authored:1/11=9%)
>>> -Chris Packham (authored:1/11=9%)
>>> -York Sun (authored:1/11=9%)
>>>
>>> Which looks bad as all the NXP folks get dropped, but they should be
>>> reading linuxppc-dev. So I think I'll merge this, unless anyone
>>> disagrees.
>>
>> They got dropped because in the absence of a maintainer entry, the
>> last committers are listed. If they need to be listed, I can send patches to
>> add
>> more specific entries for 4xx and fsl DT bindings, like:
>
> This is one is probably worth doing:
>
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index 0f1c2f96c99aa936..40b392a4f399adbe 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -5266,6 +5266,7 @@ M:Scott Wood
>> L: linuxppc-...@lists.ozlabs.org
>> L: linux-arm-ker...@lists.infradead.org
>> S: Maintained
>> +F: Documentation/devicetree/bindings/powerpc/fsl/
>> F: drivers/soc/fsl/
>> F: include/linux/fsl/
>
> I'll fold it in before applying?
Fine (less work) for me! Thanks!
> But I wouldn't bother with 4xx, just falling back to linuxppc-dev is
> fine for that.
OK.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH 3/3] kvm: arm/arm64: Fix locking for kvm_free_stage2_pgd
On 15/03/17 09:21, Christoffer Dall wrote:
> On Tue, Mar 14, 2017 at 02:52:34PM +, Suzuki K Poulose wrote:
>> In kvm_free_stage2_pgd() we don't hold the kvm->mmu_lock while calling
>> unmap_stage2_range() on the entire memory range for the guest. This could
>> cause problems with other callers (e.g, munmap on a memslot) trying to
>> unmap a range.
>>
>> Fixes: commit d5d8184d35c9 ("KVM: ARM: Memory virtualization setup")
>> Cc: sta...@vger.kernel.org # v3.10+
>> Cc: Marc Zyngier
>> Cc: Christoffer Dall
>> Signed-off-by: Suzuki K Poulose
>> ---
>> arch/arm/kvm/mmu.c | 3 +++
>> 1 file changed, 3 insertions(+)
>>
>> diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c
>> index 13b9c1f..b361f71 100644
>> --- a/arch/arm/kvm/mmu.c
>> +++ b/arch/arm/kvm/mmu.c
>> @@ -831,7 +831,10 @@ void kvm_free_stage2_pgd(struct kvm *kvm)
>> if (kvm->arch.pgd == NULL)
>> return;
>>
>> +spin_lock(&kvm->mmu_lock);
>> unmap_stage2_range(kvm, 0, KVM_PHYS_SIZE);
>> +spin_unlock(&kvm->mmu_lock);
>> +
>
> This ends up holding the spin lock for potentially quite a while, where
> we can do things like __flush_dcache_area(), which I think can fault.
I believe we're always using the linear mapping (or kmap on 32bit) in
order not to fault.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
Re: [PATCH v3 03/21] x86/xen: add CONFIG_XEN_PV to Kconfig
On 14/03/17 18:35, Vitaly Kuznetsov wrote: > All code to support Xen PV will get under this new option. For the > beginning, check for it in the common code. > > Signed-off-by: Vitaly Kuznetsov > --- > Changes since v2: >select XEN_HAVE_PVMMU moved to config XEN_PV [Juergen Gross] > --- Reviewed-by: Juergen Gross Juergen
Re: [PATCH v3 01/21] x86/xen: separate PV and HVM hypervisors
On 14/03/17 18:35, Vitaly Kuznetsov wrote: > As a preparation to splitting the code we need to untangle it: > > x86_hyper_xen -> x86_hyper_xen_hvm and x86_hyper_xen_pv > xen_platform() -> xen_platform_hvm() and xen_platform_pv() > xen_cpu_up_prepare() -> xen_cpu_up_prepare_pv() and xen_cpu_up_prepare_hvm() > xen_cpu_dead() -> xen_cpu_dead_pv() and xen_cpu_dead_pv_hvm() > > Add two parameters to xen_cpuhp_setup() to pass proper cpu_up_prepare and > cpu_dead hooks. xen_set_cpu_features() is now PV-only so the redundant > xen_pv_domain() check can be dropped. > > Signed-off-by: Vitaly Kuznetsov > --- > Changes since v2: >.pin_vcpu kept for x86_hyper_xen_hvm to support PVH Dom0 in future >[Juergen Gross] > --- Reviewed-by: Juergen Gross Juergen
Re: [PATCH v3 2/3] gpio: wm831x: Add basic device tree support
On Wed, Mar 15, 2017 at 10:18:31AM +0100, Linus Walleij wrote: > On Mon, Mar 6, 2017 at 5:46 PM, Charles Keepax > wrote: > > > Now the wm831x-core has basic DT support we can update this driver to > > allow use of the GPIOs within a device tree system. > > > > Signed-off-by: Charles Keepax > > Acked-by: Linus Walleij > > Patch applied. > This needs to go through Lee's tree with the patch above it has a build dependency on it. Thanks, Charles
Re: [PATCH 1/3] pinctrl: meson-gxbb: Fix typo in i2c ao groups
On Tue, Mar 7, 2017 at 2:31 PM, Neil Armstrong wrote: > Signed-off-by: Neil Armstrong Patch applied for fixes. Yours, Linus Walleij
Re: [PATCH v2 2/2] can: spi: hi311x: Add Holt HI-311x CAN driver
Hello Akshay,
Am 15.03.2017 um 05:44 schrieb Akshay Bhat:
Hi Wolfgang,
On Tue, Mar 14, 2017 at 2:08 PM, Wolfgang Grandegger
wrote:
...snip
/disconnect cable
can0 2088 [8] 00 00 00 19 00 00 28 00 ERRORFRAME
protocol-violation{{}{acknowledge-slot}}
bus-error
error-counter-tx-rx{{40}{0}}
can0 2088 [8] 00 00 00 19 00 00 58 00 ERRORFRAME
protocol-violation{{}{acknowledge-slot}}
bus-error
error-counter-tx-rx{{88}{0}}
can0 2088 [8] 00 00 00 19 00 00 80 00 ERRORFRAME
protocol-violation{{}{acknowledge-slot}}
bus-error
error-counter-tx-rx{{128}{0}}
TX error warning is missing.
This support was missing in the driver, added in V4 patch.
can0 208C [8] 00 20 00 19 00 00 80 00 ERRORFRAME
controller-problem{tx-error-passive}
protocol-violation{{}{acknowledge-slot}}
bus-error
error-counter-tx-rx{{128}{0}}
Here "tx-error-passiv" is packed with a bus error. What I'm looking for are
state change messages similar to:
can0 2204 [8] 00 08 00 00 00 00 60 00 ERRORFRAME
controller-problem{tx-error-warning}
state-change{tx-error-warning}
error-counter-tx-rx{{96}{0}}
can0 2204 [8] 00 30 00 00 00 00 80 00 ERRORFRAME
controller-problem{tx-error-passive}
state-change{tx-error-passive}
error-counter-tx-rx{{128}{0}
They should always come, even with "berr-reporting off".
HI-3110 has only 1 bus error interrupt. There is no dedicated state
change interrupts like other controllers.
I have little hope! Some revision of the flexcan controller have the
same problem
So here is my plan:
- Have the bus error interrupt always enabled
- If berr-reporting off, then have the isr checks/reports state changes
Error state change messages should always be there. These are the
important one.
- if berr-reporting on, then have the isr checks/reports bus errors
and state changes (Does it make sense packing the error message, if
the ISR finds both bus and state changes?)
If berr-reporting is off, simply do not create an error message for bus
errors, and only if the state changed. If it's "on" create an additional
bus error message.
http://lxr.free-electrons.com/source/drivers/net/can/flexcan.c#L334
write: No buffer space available
root@imx6qrom5420b1:~# ip -s -d link show can0
4: can0: mtu 16 qdisc pfifo_fast state UNKNOWN
mode DEFAULT group default qlen 10
link/can promiscuity 0
can state ERROR-PASSIVE (berr-counter tx 128 rx 0)
restart-ms 0
bitrate 100 sample-point 0.750
tq 62 prop-seg 5 phase-seg1 6 phase-seg2 4 sjw 1
hi3110: tseg1 2..16 tseg2 2..8 sjw 1..4 brp 1..64 brp-inc 1
clock 1600
re-started bus-errors arbit-lost error-warn error-pass bus-off
0 6 0 1 1 0
The error warning and passive counter increased , though. Also the bus error
should come in at a rather hight rate. Looking to the code, maybe
you need to test STATF to check for state changes (and not ERR).
Apologize, just realized In the above case some error packets were
lost, because I forgot to set the CPU frequency to max. Will resend
the log.
..snip...
After some more messages there should be also:
can0 2200 [8] 00 40 00 00 00 00 5F 00 ERRORFRAME
state-change{back-to-error-active}
error-counter-tx-rx{{95}{0}}
For each message sent, the error counter decreases by 8.
The HI-3110 controller decrements the error counter by 1 for every message sent.
The error count increments by 8 when there is an error.
Seems OK according to:
http://electronics.stackexchange.com/questions/220596/can-error-counters-behaviour
root@imx6qrom5420b1:~# ip -s -d link show can0
4: can0: mtu 16 qdisc pfifo_fast state UNKNOWN
mode DEFAULT group default qlen 10
link/can promiscuity 0
can state ERROR-ACTIVE (berr-counter tx 117 rx 0) restart-ms 0
bitrate 100 sample-point 0.750
tq 62 prop-seg 5 phase-seg1 6 phase-seg2 4 sjw 1
hi3110: tseg1 2..16 tseg2 2..8 sjw 1..4 brp 1..64 brp-inc 1
clock 1600
re-started bus-errors arbit-lost error-warn error-pass bus-off
0 1 0 0 0 0
Strange, some counters got lost.
This was a bug introduced when adding berr-reporting, have fixed in v4 patch.
I have not been able to check the bus-off condition by (short-circuiting
CAN low and high). The tec error count remains at 128 when I short the
CAN low and high pins and the status never goes BUSOFF.
You also need to send a message and the short-circuit should be at the
connector of the sending host. What tranceiver is used? Do you know?
ADM3054 transceiver is used with HI-3111. I connected the
HI-3111/ADM3054 board to kvaser leaf and ran "cangen -i can0" and
"candump -e any,0:
Re: [PATCH v3 00/21] x86/xen: untangle PV and PVHVM guest support code
On 14/03/17 18:35, Vitaly Kuznetsov wrote: > Changes since v2: > - Rebase to 4.11.0-rc1+ > - XEN_HAVE_PVMMU moved to config XEN_PV [Juergen Gross] > - .pin_vcpu kept for x86_hyper_xen_hvm to support PVH Dom0 in future >[Juergen Gross] > - 'extern' qualifiers dropped from newly introduced function prototypes > in headers [Juergen Gross] > - A couple of #includes added to address build issues with different > configs [kbuild test robot]. > - Juergen reviewed-bys added (hope they stand with the above mentioned > changes). They do. In case nobody objects I'll take this series for 4.12. Juergen > > The series can also be pulled from https://github.com/vittyvk/linux.git > (xen_pv_hvm_split_v3 branch). > > Some patches are known to produce checkpatch.pl WARNINGS and a couple of > ERRORs, I fixed a few (mostly in _hvm* code I split) and I refrained from > fixing the rest to make it easier to review. I think that we may leave PV > code as it is as sooner or later it will go away. > > Original description: > > I have a long-standing idea to separate PV and PVHVM code in kernel and > introduce Kconfig options to make it possible to enable the required > parts only breaking the current 'all or nothing' approach. > > Motivation: > - Xen related x86 code in kernel is rather big and it is unclear which > parts of it are required for PV, for HVM or for both. With PVH coming > into picture is becomes even more tangled. It makes it hard to > understand/audit the code. > > - In some case we may want to avoid bloating kernel by supporting Xen > guests we don't need. In particular, 90% of the code in arch/x86/xen/ is > required to support PV guests and one may require PVHVM support only. > > - PV guests are supposed to go away one day and such code separation would > help us to get ready. > > This series adds XEN_PV Kconfig option and makes it possible to build PV-only > and PVHVM-only kernels. It also makes it possible to disable Dom0 support. > > Some patches are rather big but this is mostly just moving code around, no > functional changes intended. I smoke tested it with PV-only and PVHVM-only > builds, booted and did save/restore test. I also tried the newly introduced > PVHv2 guest, it even worked! > > Vitaly Kuznetsov (21): > x86/xen: separate PV and HVM hypervisors > x86/xen: globalize have_vcpu_info_placement > x86/xen: add CONFIG_XEN_PV to Kconfig > x86/xen: split off enlighten_pvh.c > x86/xen: split off enlighten_hvm.c > x86/xen: split off enlighten_pv.c > x86/xen: split xen_smp_intr_init()/xen_smp_intr_free() > x86/xen: split xen_smp_prepare_boot_cpu() > x86/xen: split xen_cpu_die() > x86/xen: split off smp_hvm.c > x86/xen: split off smp_pv.c > x86/xen: split off mmu_hvm.c > x86/xen: split off mmu_pv.c > x86/xen: split suspend.c for PV and PVHVM guests > x86/xen: put setup.c, pmu.c and apic.c under CONFIG_XEN_PV > x86/xen: define startup_xen for XEN PV only > x86/xen: create stubs for HVM-only builds in page.h > xen/balloon: decorate PV-only parts with #ifdef CONFIG_XEN_PV > xen: create xen_create/destroy_contiguous_region() stubs for PVHVM > only builds > x86/xen: enable PVHVM-only builds > x86/xen: rename some PV-only functions in smp_pv.c > > arch/x86/include/asm/hypervisor.h |3 +- > arch/x86/include/asm/xen/page.h | 25 + > arch/x86/kernel/cpu/hypervisor.c |7 +- > arch/x86/kernel/process_64.c |2 +- > arch/x86/xen/Kconfig | 33 +- > arch/x86/xen/Makefile | 16 +- > arch/x86/xen/enlighten.c | 1925 + > arch/x86/xen/enlighten_hvm.c | 213 +++ > arch/x86/xen/enlighten_pv.c | 1522 > arch/x86/xen/enlighten_pvh.c | 115 ++ > arch/x86/xen/mmu.c| 2776 > + > arch/x86/xen/mmu_hvm.c| 79 ++ > arch/x86/xen/mmu_pv.c | 2635 +++ > arch/x86/xen/pmu.h|5 + > arch/x86/xen/smp.c| 517 +-- > arch/x86/xen/smp.h| 16 + > arch/x86/xen/smp_hvm.c| 58 + > arch/x86/xen/smp_pv.c | 500 +++ > arch/x86/xen/suspend.c| 54 - > arch/x86/xen/suspend_hvm.c| 22 + > arch/x86/xen/suspend_pv.c | 46 + > arch/x86/xen/xen-head.S |4 + > arch/x86/xen/xen-ops.h| 23 + > drivers/xen/balloon.c | 30 +- > include/xen/xen-ops.h | 14 + > 25 files changed, 5461 insertions(+), 5179 deletions(-) > create mode 100644 arch/x86/xen/enlighten_hvm.c > create mode 100644 arch/x86/xen/enlighten_pv.c > create mode 100644 arch/x86/xen/enlighten_pvh.c > create mode 100644 arch/x86/xen/mmu_hvm.c > create mode 100644 arch/x86/xen/mmu_pv.c > create mode 100644 arch/x86/xen/smp_hvm.c > create mode 100644 arch/x86/xen/smp_pv.c > create mode 100644 arch/x86/xen/suspend_
Re: [PATCH v2 2/5] mm: parallel free pages
On March 15, 2017 5:00 PM Aaron Lu wrote:
> void tlb_finish_mmu(struct mmu_gather *tlb, unsigned long start, unsigned
> long end)
> {
> + struct batch_free_struct *batch_free, *n;
> +
s/*n/*next/
> tlb_flush_mmu(tlb);
>
> /* keep the page table cache within bounds */
> check_pgt_cache();
>
> + list_for_each_entry_safe(batch_free, n, &tlb->worker_list, list) {
> + flush_work(&batch_free->work);
Not sure, list_del before free?
> + kfree(batch_free);
> + }
> +
> tlb_flush_mmu_free_batches(tlb->local.next, true);
> tlb->local.next = NULL;
> }
Re: [PATCH 2/3] pinctrl: meson-gxl: Fix inverted registers and add missing pins
On Tue, Mar 7, 2017 at 2:31 PM, Neil Armstrong wrote: > Fix some inverted bit numbers in some pinctrl groups and add missing pins > and groups to be in pair with the GXBB pinctrl pins definition. > > Signed-off-by: Neil Armstrong This does not apply on my fixes branch and possibly no other v4.11-rc1-based branch. Can you please rebase it and resend? I guess this also needs queueing for fixes? Yours, Linus Walleij
Re: [PATCH 3/3] ARM64: dts: meson-gxl: Add missing pinctrl pins groups
On Tue, Mar 7, 2017 at 2:31 PM, Neil Armstrong wrote: > Add pinctrl pins nodes following the additions of missing pins in the pinctrl > driver. > > Signed-off-by: Neil Armstrong Acked-by: Linus Walleij Please funnel this through ARM SoC or wherever meson dts files go. Yours, Linus Walleij
Re: [PATCH 1/2] pinctrl: imx: use generic pinctrl helpers for managing groups
On Tue, Mar 7, 2017 at 6:54 PM, Tony Lindgren wrote: > * Fabio Estevam [170307 09:39]: >> Hi Gary, >> >> On Tue, Mar 7, 2017 at 2:26 PM, Gary Bisson >> wrote: >> >> > No it isn't because of the use of radix but instead of: >> > http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=950b0d91dc10 >> > >> > It has been discussed here: >> > https://lkml.org/lkml/2017/2/28/140 >> >> Thanks for the clarification. >> >> > Tony offered a patch in that thread which works. Tony, have you >> > submitted it yet? >> >> Looking forward to this one :-) > > Still waiting to hear back from Linus on what he prefers. I am snowed under by mail and might be missing stuff at the moment... If there is some especially urgent fix patch I need to look into can you please point it out? Yours, Linus Walleij
Re: [PATCH 1/2] ARM64: dts: meson-gxbb-odroidc2: Add GPIO lines names
On Thu, Mar 9, 2017 at 3:52 PM, Neil Armstrong wrote: > This patch describes the GPIO lines usage on the Odroid-C2 board. > > This is useful in the debugfs gpio file and using the cdev gpio API. > > Signed-off-by: Neil Armstrong Very helpful. Reviewed-by: Linus Walleij Yours, Linus Walleij
Re: [PATCH 3/4] iio: accel: adxl345: Setup DATA_READY trigger
On Mon, Mar 13, 2017 at 02:12:54PM +0200, Andy Shevchenko wrote:
> On Mon, Mar 13, 2017 at 1:11 PM, Eva Rachel Retuya
> wrote:
>
Hello Andy,
Thanks for the review.
> Missed commit message is no-no!
>
> > Signed-off-by: Eva Rachel Retuya
>
> > -int adxl345_core_probe(struct device *dev, struct regmap *regmap,
> > - const char *name);
> > +int adxl345_core_probe(struct device *dev, struct regmap *regmap, int irq,
> > + const char *name, bool use_int2);
>
> Hmm... And tomorrow you will add another flag and another.
>
> No, consider to use something like
>
> struct adxl345_chip {
> struct device *dev;
> struct regmap *regmap;
> const char *name;
> }
>
> Convert your probe to use it, and after extend for your needs.
>
> > #define ADXL345_DEVID 0xE5
> >
> > +#define ADXL345_IRQ_NAME "adxl345_event"
>
>
> > struct adxl345_data {
> > + struct iio_trigger *drdy_trig;
> > struct regmap *regmap;
> > + bool drdy_trig_on;
> > u8 data_range;
>
> drdy -> data_ready
>
> > +static irqreturn_t adxl345_irq(int irq, void *p)
> > +{
> > + struct iio_dev *indio_dev = p;
> > + struct adxl345_data *data = iio_priv(indio_dev);
> > + int ret = IRQ_NONE;
> > + u32 int_stat;
> > +
>
> > + ret = regmap_read(data->regmap, ADXL345_REG_INT_SOURCE, &int_stat);
>
> > + if (ret < 0)
> > + return ret;
>
> It makes little sense AFAIU.
>
Can you please elaborate further your comment regarding this?
> > +
> > + if (int_stat & ADXL345_INT_DATA_READY) {
> > + iio_trigger_poll(data->drdy_trig);
> > + ret = IRQ_HANDLED;
> > + }
> > +
> > + return ret;
>
> Useless variable ret. You may return values directly.
>
> > +}
> > +
> > +static int adxl345_drdy_trigger_set_state(struct iio_trigger *trig, bool
> > state)
> > +{
> > + struct iio_dev *indio_dev = iio_trigger_get_drvdata(trig);
> > + struct adxl345_data *data = iio_priv(indio_dev);
> > + struct device *dev;
> > + int ret;
> > +
>
> > + dev = regmap_get_device(data->regmap);
>
> This may be moved to definition block.
>
> > + ret = regmap_update_bits(data->regmap, ADXL345_REG_INT_ENABLE,
>
> > +ADXL345_INT_DATA_READY, (state ?
> > +ADXL345_INT_DATA_READY : 0));
>
> No way:
> Don't split lines like this.
> Remove extra parens.
>
> > +static const struct iio_trigger_ops adxl345_trigger_ops = {
>
> > + .owner = THIS_MODULE,
>
> I dunno if we still need this.
>
> > static const struct iio_info adxl345_info = {
>
> > .driver_module = THIS_MODULE,
>
> Ditto.
>
> > .read_raw = adxl345_read_raw,
> > };
>
> > + /*
> > +* Any bits set to 0 send their respective interrupts to the INT1
> > pin,
> > +* whereas bits set to 1 send their respective interrupts to the
> > INT2
> > +* pin. Map all interrupts to the specified pin.
> > +*/
>
> > + if (!use_int2)
> > + ret = regmap_write(data->regmap, ADXL345_REG_INT_MAP, 0x00);
> > + else
> > + ret = regmap_write(data->regmap, ADXL345_REG_INT_MAP, 0xFF);
>
> I would create a temporary variable to hold the value and call
> regmap_write() unconditionally.
>
>
> > - return iio_device_register(indio_dev);
>
> You are not supposed to ping-pong changes in your series. Make clear
> your goal either you do like above or like below. If you choose
> latter, don't alter it in previous patch.
>
Ack. Will revise carefully with consideration to your comments in this
whole series.
> > + if (irq > 0) {
>
> > + ret =
> > + devm_request_threaded_irq(dev, irq, NULL, adxl345_irq,
>
> Don't split lines like this.
>
> > + IRQF_TRIGGER_HIGH | IRQF_ONESHOT,
>
> Are you sure you have threaded IRQ handler?
>
> > + ret = iio_device_register(indio_dev);
> > + if (ret < 0) {
> > + dev_err(dev, "iio_device_register failed: %d\n", ret);
> > + goto err_trigger_unregister;
> > + }
> > +
> > + return ret;
>
> > +err_trigger_unregister:
> > + if (data->drdy_trig)
> > + iio_trigger_unregister(data->drdy_trig);
> > +
> > + return ret;
>
> So, doesn't devm_iio_*() provide a facility to avoid this?
>
> > @@ -229,6 +334,8 @@ int adxl345_core_remove(struct device *dev)
> > struct adxl345_data *data = iio_priv(indio_dev);
> >
> > iio_device_unregister(indio_dev);
> > + if (data->drdy_trig)
> > + iio_trigger_unregister(data->drdy_trig);
>
> Ditto.
>
> > --- a/drivers/iio/accel/adxl345_i2c.c
> > +++ b/drivers/iio/accel/adxl345_i2c.c
>
> > - return adxl345_core_probe(&client->dev, regmap, id ? id->name :
> > NULL);
> > + irq = of_irq_get_byname(
Re: [PATCH 2/3] pinctrl: meson-gxl: Fix inverted registers and add missing pins
On 03/15/2017 10:43 AM, Linus Walleij wrote: > On Tue, Mar 7, 2017 at 2:31 PM, Neil Armstrong > wrote: > >> Fix some inverted bit numbers in some pinctrl groups and add missing pins >> and groups to be in pair with the GXBB pinctrl pins definition. >> >> Signed-off-by: Neil Armstrong > > This does not apply on my fixes branch and possibly no other > v4.11-rc1-based branch. Can you please rebase it and resend? > > I guess this also needs queueing for fixes? > > Yours, > Linus Walleij > Hi Linus, Indeed, it depends on Martin's "pinctrl: meson: gxl: add the missing PWM pin definitions" posted earlier. Neil
Re: [PATCH 00/19] fixup usage of non-raw spinlocks in irqchips
On Thu, Mar 9, 2017 at 5:21 PM, Julia Cartwright wrote: > The following patchset introduces a new coccinelle patch, > irq_chip_raw_spinlock.cocci, which is used to identify irq_chip implementors > which acquire/release non-raw spinlocks, and in addition, a set of generated > patches for most cases identified. Wow that is really impressive. I expect to apply all that are applicable to GPIO drivers. I guess this really lowers the bar to run realtime on a whole slew of systems. Yours, Linus Walleij
[PATCH v3 2/8] staging: rtl8192e: Fix coding style
From: Suniel Mahesh
Fixed the following checkpatch.pl warning:
line over 80 characters
Signed-off-by: Suniel Mahesh
---
Changes for v3:
- Split earlier patches into multiple commits for easy review
as suggested by Greg K-H
- New patch addition to the series
- Rebased on top of next-20170310
- Patches were tested and built on next-20170310 and staging-testing
as suggested by Greg K-H, no errors reported
Changes for v2:
---
drivers/staging/rtl8192e/rtl8192e/rtl_core.c | 30 +++-
1 file changed, 16 insertions(+), 14 deletions(-)
diff --git a/drivers/staging/rtl8192e/rtl8192e/rtl_core.c
b/drivers/staging/rtl8192e/rtl8192e/rtl_core.c
index a648064..eb2321c 100644
--- a/drivers/staging/rtl8192e/rtl8192e/rtl_core.c
+++ b/drivers/staging/rtl8192e/rtl8192e/rtl_core.c
@@ -218,7 +218,7 @@ bool rtl92e_set_rf_state(struct net_device *dev,
else
priv->blinked_ingpio = false;
rtllib_MgntDisconnect(priv->rtllib,
-
WLAN_REASON_DISASSOC_STA_HAS_LEFT);
+ WLAN_REASON_DISASSOC_STA_HAS_LEFT);
}
}
if ((ChangeSource == RF_CHANGE_BY_HW) && !priv->bHwRadioOff)
@@ -1796,7 +1796,7 @@ static short _rtl92e_alloc_rx_ring(struct net_device *dev)
for (rx_queue_idx = 0; rx_queue_idx < MAX_RX_QUEUE; rx_queue_idx++) {
priv->rx_ring[rx_queue_idx] = pci_zalloc_consistent(priv->pdev,
-
sizeof(*priv->rx_ring[rx_queue_idx]) * priv->rxringcount,
+ sizeof(*priv->rx_ring[rx_queue_idx]) * priv->rxringcount,
&priv->rx_ring_dma[rx_queue_idx]);
if (!priv->rx_ring[rx_queue_idx] ||
(unsigned long)priv->rx_ring[rx_queue_idx] & 0xFF) {
@@ -2272,7 +2272,8 @@ static int _rtl92e_ioctl(struct net_device *dev, struct
ifreq *rq, int cmd)
int ret = -1;
struct rtllib_device *ieee = priv->rtllib;
u32 key[4];
- const u8 broadcast_addr[ETH_ALEN] = {0xff, 0xff, 0xff, 0xff, 0xff,
0xff};
+ const u8 broadcast_addr[ETH_ALEN] = {0xff, 0xff, 0xff, 0xff, 0xff,
+ 0xff};
struct iw_point *p = &wrq->u.data;
struct ieee_param *ipw = NULL;
@@ -2309,14 +2310,15 @@ static int _rtl92e_ioctl(struct net_device *dev, struct
ifreq *rq, int cmd)
}
if (ieee->pairwise_key_type) {
- if
(is_zero_ether_addr(ieee->ap_mac_addr))
+ if (is_zero_ether_addr(
+ ieee->ap_mac_addr))
ieee->iw_mode = IW_MODE_ADHOC;
memcpy((u8 *)key, ipw->u.crypt.key, 16);
rtl92e_enable_hw_security_config(dev);
rtl92e_set_swcam(dev, 4,
ipw->u.crypt.idx,
-
ieee->pairwise_key_type,
-(u8
*)ieee->ap_mac_addr,
+ ieee->pairwise_key_type,
+ (u8 *)ieee->ap_mac_addr,
0, key, 0);
rtl92e_set_key(dev, 4, ipw->u.crypt.idx,
ieee->pairwise_key_type,
@@ -2324,17 +2326,17 @@ static int _rtl92e_ioctl(struct net_device *dev, struct
ifreq *rq, int cmd)
0, key);
if (ieee->iw_mode == IW_MODE_ADHOC) {
rtl92e_set_swcam(dev,
-
ipw->u.crypt.idx,
-
ipw->u.crypt.idx,
-
ieee->pairwise_key_type,
-(u8
*)ieee->ap_mac_addr,
-0, key, 0);
+ ipw->u.crypt.idx,
+ ipw->u.crypt.idx,
+ ieee->pairwise_key_type,
+ (u8 *)ieee->ap_mac_addr,
+ 0, key, 0);
[PATCH v3 5/8] staging: rtl8192e: Fix unbalanced braces
From: Suniel Mahesh
Fixed unbalanced braces around else statement
Add braces on all arms of the if-else statements to comply with
kernel coding style.
Signed-off-by: Suniel Mahesh
---
Changes for v3:
- Split earlier patches into multiple commits for easy review
as suggested by Greg K-H
- Modified subject and description for better readability
- Rebased on top of next-20170310
- Patches were tested and built on next-20170310 and staging-testing
as suggested by Greg K-H, no errors reported
Changes for v2:
- new patch addition to the series
- Rebased on top of next-20170306
---
drivers/staging/rtl8192e/rtl8192e/rtl_core.c | 30 +---
1 file changed, 18 insertions(+), 12 deletions(-)
diff --git a/drivers/staging/rtl8192e/rtl8192e/rtl_core.c
b/drivers/staging/rtl8192e/rtl8192e/rtl_core.c
index 0fa4017..c355ee7 100644
--- a/drivers/staging/rtl8192e/rtl8192e/rtl_core.c
+++ b/drivers/staging/rtl8192e/rtl8192e/rtl_core.c
@@ -2294,17 +2294,20 @@ static int _rtl92e_ioctl(struct net_device *dev, struct
ifreq *rq, int cmd)
if (ipw->cmd == IEEE_CMD_SET_ENCRYPTION) {
if (ipw->u.crypt.set_tx) {
- if (strcmp(ipw->u.crypt.alg, "CCMP") == 0)
+ if (strcmp(ipw->u.crypt.alg, "CCMP") == 0) {
ieee->pairwise_key_type = KEY_TYPE_CCMP;
- else if (strcmp(ipw->u.crypt.alg, "TKIP") == 0)
+ } else if (strcmp(ipw->u.crypt.alg,
+ "TKIP") == 0) {
ieee->pairwise_key_type = KEY_TYPE_TKIP;
- else if (strcmp(ipw->u.crypt.alg, "WEP") == 0) {
- if (ipw->u.crypt.key_len == 13)
+ } else if (strcmp(ipw->u.crypt.alg,
+ "WEP") == 0) {
+ if (ipw->u.crypt.key_len == 13) {
ieee->pairwise_key_type =
KEY_TYPE_WEP104;
- else if (ipw->u.crypt.key_len == 5)
+ } else if (ipw->u.crypt.key_len == 5) {
ieee->pairwise_key_type =
KEY_TYPE_WEP40;
+ }
} else {
ieee->pairwise_key_type = KEY_TYPE_NA;
}
@@ -2346,20 +2349,23 @@ static int _rtl92e_ioctl(struct net_device *dev, struct
ifreq *rq, int cmd)
} else {
memcpy((u8 *)key, ipw->u.crypt.key, 16);
- if (strcmp(ipw->u.crypt.alg, "CCMP") == 0)
+ if (strcmp(ipw->u.crypt.alg, "CCMP") == 0) {
ieee->group_key_type = KEY_TYPE_CCMP;
- else if (strcmp(ipw->u.crypt.alg, "TKIP") == 0)
+ } else if (strcmp(ipw->u.crypt.alg,
+ "TKIP") == 0) {
ieee->group_key_type = KEY_TYPE_TKIP;
- else if (strcmp(ipw->u.crypt.alg, "WEP") == 0) {
- if (ipw->u.crypt.key_len == 13)
+ } else if (strcmp(ipw->u.crypt.alg,
+ "WEP") == 0) {
+ if (ipw->u.crypt.key_len == 13) {
ieee->group_key_type =
KEY_TYPE_WEP104;
- else if (ipw->u.crypt.key_len == 5)
+ } else if (ipw->u.crypt.key_len == 5) {
ieee->group_key_type =
KEY_TYPE_WEP40;
- } else
+ }
+ } else {
ieee->group_key_type = KEY_TYPE_NA;
-
+ }
if (ieee->group_key_type) {
rtl92e_set_swcam(dev, ipw->u.crypt.idx,
ipw->u.crypt.idx,
--
1.9.1
