- Linux-stable-mirror - lists.linaro.org

Patch "ARM: dts: omap3-n900: Fix the audio CODEC's reset pin" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ARM: dts: omap3-n900: Fix the audio CODEC's reset pin to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: arm-dts-omap3-n900-fix-the-audio-codec-s-reset-pin.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Mar 19 09:58:12 CET 2018 From: "Andrew F. Davis" <afd(a)ti.com> Date: Wed, 29 Nov 2017 11:13:59 -0600 Subject: ARM: dts: omap3-n900: Fix the audio CODEC's reset pin From: "Andrew F. Davis" <afd(a)ti.com> [ Upstream commit 7be4b5dc7ffa9499ac6ef33a5ffa9ff43f9b7057 ] The correct DT property for specifying a GPIO used for reset is "reset-gpios", fix this here. Fixes: 14e3e295b2b9 ("ARM: dts: omap3-n900: Add TLV320AIC3X support") Signed-off-by: Andrew F. Davis <afd(a)ti.com> Signed-off-by: Tony Lindgren <tony(a)atomide.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/arm/boot/dts/omap3-n900.dts | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/arch/arm/boot/dts/omap3-n900.dts +++ b/arch/arm/boot/dts/omap3-n900.dts @@ -488,7 +488,7 @@ tlv320aic3x: tlv320aic3x@18 { compatible = "ti,tlv320aic3x"; reg = <0x18>; - gpio-reset = <&gpio2 28 GPIO_ACTIVE_HIGH>; /* 60 */ + reset-gpios = <&gpio2 28 GPIO_ACTIVE_LOW>; /* 60 */ ai3x-gpio-func = < 0 /* AIC3X_GPIO1_FUNC_DISABLED */ 5 /* AIC3X_GPIO2_FUNC_DIGITAL_MIC_INPUT */ @@ -505,7 +505,7 @@ tlv320aic3x_aux: tlv320aic3x@19 { compatible = "ti,tlv320aic3x"; reg = <0x19>; - gpio-reset = <&gpio2 28 GPIO_ACTIVE_HIGH>; /* 60 */ + reset-gpios = <&gpio2 28 GPIO_ACTIVE_LOW>; /* 60 */ AVDD-supply = <&vmmc2>; DRVDD-supply = <&vmmc2>; Patches currently in stable-queue which might be from afd(a)ti.com are queue-4.4/arm-dts-omap3-n900-fix-the-audio-codec-s-reset-pin.patch queue-4.4/arm-dts-am335x-pepper-fix-the-audio-codec-s-reset-pin.patch

7 years, 6 months

1
0
0 0

Patch "ARM: dts: koelsch: Correct clock frequency of X2 DU clock input" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ARM: dts: koelsch: Correct clock frequency of X2 DU clock input to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: arm-dts-koelsch-correct-clock-frequency-of-x2-du-clock-input.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Mar 19 09:58:12 CET 2018 From: Geert Uytterhoeven <geert+renesas(a)glider.be> Date: Mon, 3 Apr 2017 11:55:19 +0200 Subject: ARM: dts: koelsch: Correct clock frequency of X2 DU clock input From: Geert Uytterhoeven <geert+renesas(a)glider.be> [ Upstream commit ebf06af55c7594ed1fc18469a5cddf911c40e687 ] The X2 crystal oscillator on the Koelsch development board provides a 74.25 MHz clock, not a 148.5 MHz clock. Fixes: cd21cb46e14aae3a ("ARM: shmobile: koelsch: Add DU external pixel clocks to DT") Signed-off-by: Geert Uytterhoeven <geert+renesas(a)glider.be> Acked-by: Laurent Pinchart <laurent.pinchart(a)ideasonboard.com> Tested-by: Niklas Söderlund <niklas.soderlund+renesas(a)ragnatech.se> Signed-off-by: Simon Horman <horms+renesas(a)verge.net.au> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/arm/boot/dts/r8a7791-koelsch.dts | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/arch/arm/boot/dts/r8a7791-koelsch.dts +++ b/arch/arm/boot/dts/r8a7791-koelsch.dts @@ -280,7 +280,7 @@ x2_clk: x2-clock { compatible = "fixed-clock"; #clock-cells = <0>; - clock-frequency = <148500000>; + clock-frequency = <74250000>; }; x13_clk: x13-clock { Patches currently in stable-queue which might be from geert+renesas(a)glider.be are queue-4.4/arm-dts-r8a7791-correct-parent-of-ssi-clocks.patch queue-4.4/arm-dts-koelsch-correct-clock-frequency-of-x2-du-clock-input.patch queue-4.4/arm-dts-r8a7790-correct-parent-of-ssi-clocks.patch

7 years, 6 months

1
0
0 0

Patch "ARM: dts: exynos: Correct Trats2 panel reset line" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ARM: dts: exynos: Correct Trats2 panel reset line to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: arm-dts-exynos-correct-trats2-panel-reset-line.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Mar 19 09:58:12 CET 2018 From: Simon Shields <simon(a)lineageos.org> Date: Tue, 21 Nov 2017 22:24:24 +1100 Subject: ARM: dts: exynos: Correct Trats2 panel reset line From: Simon Shields <simon(a)lineageos.org> [ Upstream commit 1b377924841df1e13ab5b225be3a83f807a92b52 ] Trats2 uses gpf2-1 as the panel reset GPIO. gpy4-5 was only used on early revisions of the board. Fixes: 420ae8451a22 ("ARM: dts: exynos4412-trats2: add panel node") Signed-off-by: Simon Shields <simon(a)lineageos.org> Acked-by: Marek Szyprowski <m.szyprowski(a)samsung.com> Tested-by: Marek Szyprowski <m.szyprowski(a)samsung.com> Signed-off-by: Krzysztof Kozlowski <krzk(a)kernel.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/arm/boot/dts/exynos4412-trats2.dts | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/arch/arm/boot/dts/exynos4412-trats2.dts +++ b/arch/arm/boot/dts/exynos4412-trats2.dts @@ -359,7 +359,7 @@ reg = <0>; vdd3-supply = <&lcd_vdd3_reg>; vci-supply = <&ldo25_reg>; - reset-gpios = <&gpy4 5 GPIO_ACTIVE_HIGH>; + reset-gpios = <&gpf2 1 GPIO_ACTIVE_HIGH>; power-on-delay= <50>; reset-delay = <100>; init-delay = <100>; Patches currently in stable-queue which might be from simon(a)lineageos.org are queue-4.4/arm-dts-exynos-correct-trats2-panel-reset-line.patch

7 years, 6 months

1
0
0 0

Patch "ARM: dts: am335x-pepper: Fix the audio CODEC's reset pin" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ARM: dts: am335x-pepper: Fix the audio CODEC's reset pin to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: arm-dts-am335x-pepper-fix-the-audio-codec-s-reset-pin.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Mar 19 09:58:12 CET 2018 From: "Andrew F. Davis" <afd(a)ti.com> Date: Wed, 29 Nov 2017 11:13:56 -0600 Subject: ARM: dts: am335x-pepper: Fix the audio CODEC's reset pin From: "Andrew F. Davis" <afd(a)ti.com> [ Upstream commit e153db03c6b7a035c797bcdf35262586f003ee93 ] The correct DT property for specifying a GPIO used for reset is "reset-gpios", fix this here. Fixes: 4341881d0562 ("ARM: dts: Add devicetree for Gumstix Pepper board") Signed-off-by: Andrew F. Davis <afd(a)ti.com> Signed-off-by: Tony Lindgren <tony(a)atomide.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/arm/boot/dts/am335x-pepper.dts | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/arch/arm/boot/dts/am335x-pepper.dts +++ b/arch/arm/boot/dts/am335x-pepper.dts @@ -139,7 +139,7 @@ &audio_codec { status = "okay"; - gpio-reset = <&gpio1 16 GPIO_ACTIVE_LOW>; + reset-gpios = <&gpio1 16 GPIO_ACTIVE_LOW>; AVDD-supply = <&ldo3_reg>; IOVDD-supply = <&ldo3_reg>; DRVDD-supply = <&ldo3_reg>; Patches currently in stable-queue which might be from afd(a)ti.com are queue-4.4/arm-dts-omap3-n900-fix-the-audio-codec-s-reset-pin.patch queue-4.4/arm-dts-am335x-pepper-fix-the-audio-codec-s-reset-pin.patch

7 years, 6 months

1
0
0 0

Patch "ARM: dts: Adjust moxart IRQ controller and flags" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ARM: dts: Adjust moxart IRQ controller and flags to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: arm-dts-adjust-moxart-irq-controller-and-flags.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Mar 19 09:58:12 CET 2018 From: Linus Walleij <linus.walleij(a)linaro.org> Date: Sat, 18 Mar 2017 17:40:01 +0100 Subject: ARM: dts: Adjust moxart IRQ controller and flags From: Linus Walleij <linus.walleij(a)linaro.org> [ Upstream commit c2a736b698008d296c5010ec39077eeb5796109f ] The moxart interrupt line flags were not respected in previous driver: instead of assigning them per-consumer, a fixes mask was set in the controller. With the migration to a standard Faraday driver we need to set up and handle the consumer flags correctly. Also remove the Moxart-specific flags when switching to using real consumer flags. Extend the register window to 0x100 bytes as we may have a few more registers in there and it doesn't hurt. Tested-by: Jonas Jensen <jonas.jensen(a)gmail.com> Signed-off-by: Jonas Jensen <jonas.jensen(a)gmail.com> Signed-off-by: Linus Walleij <linus.walleij(a)linaro.org> Signed-off-by: Olof Johansson <olof(a)lixom.net> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/arm/boot/dts/moxart-uc7112lx.dts | 2 +- arch/arm/boot/dts/moxart.dtsi | 17 +++++++++-------- 2 files changed, 10 insertions(+), 9 deletions(-) --- a/arch/arm/boot/dts/moxart-uc7112lx.dts +++ b/arch/arm/boot/dts/moxart-uc7112lx.dts @@ -6,7 +6,7 @@ */ /dts-v1/; -/include/ "moxart.dtsi" +#include "moxart.dtsi" / { model = "MOXA UC-7112-LX"; --- a/arch/arm/boot/dts/moxart.dtsi +++ b/arch/arm/boot/dts/moxart.dtsi @@ -6,6 +6,7 @@ */ /include/ "skeleton.dtsi" +#include <dt-bindings/interrupt-controller/irq.h> / { compatible = "moxa,moxart"; @@ -36,8 +37,8 @@ ranges; intc: interrupt-controller@98800000 { - compatible = "moxa,moxart-ic"; - reg = <0x98800000 0x38>; + compatible = "moxa,moxart-ic", "faraday,ftintc010"; + reg = <0x98800000 0x100>; interrupt-controller; #interrupt-cells = <2>; interrupt-mask = <0x00080000>; @@ -59,7 +60,7 @@ timer: timer@98400000 { compatible = "moxa,moxart-timer"; reg = <0x98400000 0x42>; - interrupts = <19 1>; + interrupts = <19 IRQ_TYPE_EDGE_FALLING>; clocks = <&clk_apb>; }; @@ -80,7 +81,7 @@ dma: dma@90500000 { compatible = "moxa,moxart-dma"; reg = <0x90500080 0x40>; - interrupts = <24 0>; + interrupts = <24 IRQ_TYPE_LEVEL_HIGH>; #dma-cells = <1>; }; @@ -93,7 +94,7 @@ sdhci: sdhci@98e00000 { compatible = "moxa,moxart-sdhci"; reg = <0x98e00000 0x5C>; - interrupts = <5 0>; + interrupts = <5 IRQ_TYPE_LEVEL_HIGH>; clocks = <&clk_apb>; dmas = <&dma 5>, <&dma 5>; @@ -120,7 +121,7 @@ mac0: mac@90900000 { compatible = "moxa,moxart-mac"; reg = <0x90900000 0x90>; - interrupts = <25 0>; + interrupts = <25 IRQ_TYPE_LEVEL_HIGH>; phy-handle = <&ethphy0>; phy-mode = "mii"; status = "disabled"; @@ -129,7 +130,7 @@ mac1: mac@92000000 { compatible = "moxa,moxart-mac"; reg = <0x92000000 0x90>; - interrupts = <27 0>; + interrupts = <27 IRQ_TYPE_LEVEL_HIGH>; phy-handle = <&ethphy1>; phy-mode = "mii"; status = "disabled"; @@ -138,7 +139,7 @@ uart0: uart@98200000 { compatible = "ns16550a"; reg = <0x98200000 0x20>; - interrupts = <31 8>; + interrupts = <31 IRQ_TYPE_LEVEL_HIGH>; reg-shift = <2>; reg-io-width = <4>; clock-frequency = <14745600>; Patches currently in stable-queue which might be from linus.walleij(a)linaro.org are queue-4.4/arm-dts-adjust-moxart-irq-controller-and-flags.patch

7 years, 6 months

1
0
0 0

Patch "apparmor: Make path_max parameter readonly" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled apparmor: Make path_max parameter readonly to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: apparmor-make-path_max-parameter-readonly.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Mar 19 09:58:12 CET 2018 From: John Johansen <john.johansen(a)canonical.com> Date: Thu, 6 Apr 2017 06:55:24 -0700 Subject: apparmor: Make path_max parameter readonly From: John Johansen <john.johansen(a)canonical.com> [ Upstream commit 622f6e3265707ebf02ba776ac6e68003bcc31213 ] The path_max parameter determines the max size of buffers allocated but it should not be setable at run time. If can be used to cause an oops root@ubuntu:~# echo 16777216 > /sys/module/apparmor/parameters/path_max root@ubuntu:~# cat /sys/module/apparmor/parameters/path_max Killed [ 122.141911] BUG: unable to handle kernel paging request at ffff880080945fff [ 122.143497] IP: [<ffffffff81228844>] d_absolute_path+0x44/0xa0 [ 122.144742] PGD 220c067 PUD 0 [ 122.145453] Oops: 0002 [#1] SMP [ 122.146204] Modules linked in: vmw_vsock_vmci_transport vsock ppdev vmw_balloon snd_ens1371 btusb snd_ac97_codec gameport snd_rawmidi btrtl snd_seq_device ac97_bus btbcm btintel snd_pcm input_leds bluetooth snd_timer snd joydev soundcore serio_raw coretemp shpchp nfit parport_pc i2c_piix4 8250_fintek vmw_vmci parport mac_hid ib_iser rdma_cm iw_cm ib_cm ib_sa ib_mad ib_core ib_addr iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi autofs4 btrfs raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c raid1 raid0 multipath linear hid_generic usbhid hid crct10dif_pclmul crc32_pclmul ghash_clmulni_intel aesni_intel aes_x86_64 lrw gf128mul glue_helper ablk_helper cryptd vmwgfx psmouse mptspi ttm mptscsih drm_kms_helper mptbase syscopyarea scsi_transport_spi sysfillrect [ 122.163365] ahci sysimgblt e1000 fb_sys_fops libahci drm pata_acpi fjes [ 122.164747] CPU: 3 PID: 1501 Comm: bash Not tainted 4.4.0-59-generic #80-Ubuntu [ 122.166250] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 07/02/2015 [ 122.168611] task: ffff88003496aa00 ti: ffff880076474000 task.ti: ffff880076474000 [ 122.170018] RIP: 0010:[<ffffffff81228844>] [<ffffffff81228844>] d_absolute_path+0x44/0xa0 [ 122.171525] RSP: 0018:ffff880076477b90 EFLAGS: 00010206 [ 122.172462] RAX: ffff880080945fff RBX: 0000000000000000 RCX: 0000000001000000 [ 122.173709] RDX: 0000000000ffffff RSI: ffff880080946000 RDI: ffff8800348a1010 [ 122.174978] RBP: ffff880076477bb8 R08: ffff880076477c80 R09: 0000000000000000 [ 122.176227] R10: 00007ffffffff000 R11: ffff88007f946000 R12: ffff88007f946000 [ 122.177496] R13: ffff880076477c80 R14: ffff8800348a1010 R15: ffff8800348a2400 [ 122.178745] FS: 00007fd459eb4700(0000) GS:ffff88007b6c0000(0000) knlGS:0000000000000000 [ 122.180176] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 122.181186] CR2: ffff880080945fff CR3: 0000000073422000 CR4: 00000000001406e0 [ 122.182469] Stack: [ 122.182843] 00ffffff00000001 ffff880080946000 0000000000000000 0000000000000000 [ 122.184409] 00000000570f789c ffff880076477c30 ffffffff81385671 ffff88007a2e7a58 [ 122.185810] 0000000000000000 ffff880076477c88 01000000008a1000 0000000000000000 [ 122.187231] Call Trace: [ 122.187680] [<ffffffff81385671>] aa_path_name+0x81/0x370 [ 122.188637] [<ffffffff813875dd>] profile_transition+0xbd/0xb80 [ 122.190181] [<ffffffff811af9bc>] ? zone_statistics+0x7c/0xa0 [ 122.191674] [<ffffffff81389b20>] apparmor_bprm_set_creds+0x9b0/0xac0 [ 122.193288] [<ffffffff812e1971>] ? ext4_xattr_get+0x81/0x220 [ 122.194793] [<ffffffff812e800c>] ? ext4_xattr_security_get+0x1c/0x30 [ 122.196392] [<ffffffff813449b9>] ? get_vfs_caps_from_disk+0x69/0x110 [ 122.198004] [<ffffffff81232d4f>] ? mnt_may_suid+0x3f/0x50 [ 122.199737] [<ffffffff81344b03>] ? cap_bprm_set_creds+0xa3/0x600 [ 122.201377] [<ffffffff81346e53>] security_bprm_set_creds+0x33/0x50 [ 122.203024] [<ffffffff81214ce5>] prepare_binprm+0x85/0x190 [ 122.204515] [<ffffffff81216545>] do_execveat_common.isra.33+0x485/0x710 [ 122.206200] [<ffffffff81216a6a>] SyS_execve+0x3a/0x50 [ 122.207615] [<ffffffff81838795>] stub_execve+0x5/0x5 [ 122.208978] [<ffffffff818384f2>] ? entry_SYSCALL_64_fastpath+0x16/0x71 [ 122.210615] Code: f8 31 c0 48 63 c2 83 ea 01 48 c7 45 e8 00 00 00 00 48 01 c6 85 d2 48 c7 45 f0 00 00 00 00 48 89 75 e0 89 55 dc 78 0c 48 8d 46 ff <c6> 46 ff 00 48 89 45 e0 48 8d 55 e0 48 8d 4d dc 48 8d 75 e8 e8 [ 122.217320] RIP [<ffffffff81228844>] d_absolute_path+0x44/0xa0 [ 122.218860] RSP <ffff880076477b90> [ 122.219919] CR2: ffff880080945fff [ 122.220936] ---[ end trace 506cdbd85eb6c55e ]--- Reported-by: Tetsuo Handa <penguin-kernel(a)I-love.SAKURA.ne.jp> Signed-off-by: John Johansen <john.johansen(a)canonical.com> Signed-off-by: James Morris <james.l.morris(a)oracle.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- security/apparmor/lsm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/security/apparmor/lsm.c +++ b/security/apparmor/lsm.c @@ -722,7 +722,7 @@ module_param_named(logsyscall, aa_g_logs /* Maximum pathname length before accesses will start getting rejected */ unsigned int aa_g_path_max = 2 * PATH_MAX; -module_param_named(path_max, aa_g_path_max, aauint, S_IRUSR | S_IWUSR); +module_param_named(path_max, aa_g_path_max, aauint, S_IRUSR); /* Determines how paranoid loading of policy is and how much verification * on the loaded policy is done. Patches currently in stable-queue which might be from john.johansen(a)canonical.com are queue-4.4/apparmor-make-path_max-parameter-readonly.patch

7 years, 6 months

1
0
0 0

Patch "ARM: DRA7: hwmod_data: Prevent wait_target_disable error for usb_otg_ss" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ARM: DRA7: hwmod_data: Prevent wait_target_disable error for usb_otg_ss to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: arm-dra7-hwmod_data-prevent-wait_target_disable-error-for-usb_otg_ss.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Mar 19 09:58:12 CET 2018 From: Roger Quadros <rogerq(a)ti.com> Date: Mon, 13 Mar 2017 13:53:16 +0200 Subject: ARM: DRA7: hwmod_data: Prevent wait_target_disable error for usb_otg_ss From: Roger Quadros <rogerq(a)ti.com> [ Upstream commit e2d54fe76997301b49311bde7ba8ef52b47896f9 ] It seems that if L3_INIT clkdomain is kept in HW_AUTO while usb_otg_ss is in use then there are random chances that the usb_otg_ss module will fail to completely idle. i.e. IDLEST = 0x2 instead of 0x3. Preventing L3_INIT from HW_AUTO while usb_otg_ss module is in use fixes this issue. We don't know yet if usb_otg_ss instances 3 and 4 are affected by this issue or not so don't add this flag for those instances. Cc: Tero Kristo <t-kristo(a)ti.com> Signed-off-by: Roger Quadros <rogerq(a)ti.com> Signed-off-by: Tony Lindgren <tony(a)atomide.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 2 ++ 1 file changed, 2 insertions(+) --- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c +++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c @@ -2240,6 +2240,7 @@ static struct omap_hwmod dra7xx_usb_otg_ .class = &dra7xx_usb_otg_ss_hwmod_class, .clkdm_name = "l3init_clkdm", .main_clk = "dpll_core_h13x2_ck", + .flags = HWMOD_CLKDM_NOAUTO, .prcm = { .omap4 = { .clkctrl_offs = DRA7XX_CM_L3INIT_USB_OTG_SS1_CLKCTRL_OFFSET, @@ -2261,6 +2262,7 @@ static struct omap_hwmod dra7xx_usb_otg_ .class = &dra7xx_usb_otg_ss_hwmod_class, .clkdm_name = "l3init_clkdm", .main_clk = "dpll_core_h13x2_ck", + .flags = HWMOD_CLKDM_NOAUTO, .prcm = { .omap4 = { .clkctrl_offs = DRA7XX_CM_L3INIT_USB_OTG_SS2_CLKCTRL_OFFSET, Patches currently in stable-queue which might be from rogerq(a)ti.com are queue-4.4/arm-dra7-hwmod_data-prevent-wait_target_disable-error-for-usb_otg_ss.patch

7 years, 6 months

1
0
0 0

Patch "ALSA: firewire-digi00x: handle all MIDI messages on streaming packets" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ALSA: firewire-digi00x: handle all MIDI messages on streaming packets to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: alsa-firewire-digi00x-handle-all-midi-messages-on-streaming-packets.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Mar 19 09:58:12 CET 2018 From: Takashi Sakamoto <o-takashi(a)sakamocchi.jp> Date: Sun, 2 Apr 2017 23:48:25 +0900 Subject: ALSA: firewire-digi00x: handle all MIDI messages on streaming packets From: Takashi Sakamoto <o-takashi(a)sakamocchi.jp> [ Upstream commit 8820a4cf0cb4cd5c6540a9a18b2cedbdfd5a6891 ] At a commit 9dc5d31cdceb ("ALSA: firewire-digi00x: handle MIDI messages in isochronous packets"), a functionality to handle MIDI messages on isochronous packet was supported. But this includes some of my misunderstanding. This commit is to fix them. For digi00x series, first data channel of data blocks in rx/tx packet includes MIDI messages. The data channel has 0x80 in 8 bit of its MSB, however it's against IEC 61883-6. Unique data format is applied: - Upper 4 bits of LSB represent port number. - 0x0: port 1. - 0x2: port 2. - 0xe: console port. - Lower 4 bits of LSB represent the number of included MIDI message bytes; 0x0/0x1/0x2. - Two bytes of middle of this data channel have MIDI bytes. Especially, MIDI messages from/to console surface are also transferred by isochronous packets, as well as physical MIDI ports. Signed-off-by: Takashi Sakamoto <o-takashi(a)sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai(a)suse.de> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- sound/firewire/digi00x/amdtp-dot.c | 53 +++++++++++++++++++++++++------------ 1 file changed, 36 insertions(+), 17 deletions(-) --- a/sound/firewire/digi00x/amdtp-dot.c +++ b/sound/firewire/digi00x/amdtp-dot.c @@ -28,6 +28,9 @@ */ #define MAX_MIDI_RX_BLOCKS 8 +/* 3 = MAX(DOT_MIDI_IN_PORTS, DOT_MIDI_OUT_PORTS) + 1. */ +#define MAX_MIDI_PORTS 3 + /* * The double-oh-three algorithm was discovered by Robin Gareus and Damien * Zammit in 2012, with reverse-engineering for Digi 003 Rack. @@ -42,10 +45,8 @@ struct amdtp_dot { unsigned int pcm_channels; struct dot_state state; - unsigned int midi_ports; - /* 2 = MAX(DOT_MIDI_IN_PORTS, DOT_MIDI_OUT_PORTS) */ - struct snd_rawmidi_substream *midi[2]; - int midi_fifo_used[2]; + struct snd_rawmidi_substream *midi[MAX_MIDI_PORTS]; + int midi_fifo_used[MAX_MIDI_PORTS]; int midi_fifo_limit; void (*transfer_samples)(struct amdtp_stream *s, @@ -124,8 +125,8 @@ int amdtp_dot_set_parameters(struct amdt return -EBUSY; /* - * A first data channel is for MIDI conformant data channel, the rest is - * Multi Bit Linear Audio data channel. + * A first data channel is for MIDI messages, the rest is Multi Bit + * Linear Audio data channel. */ err = amdtp_stream_set_parameters(s, rate, pcm_channels + 1); if (err < 0) @@ -135,11 +136,6 @@ int amdtp_dot_set_parameters(struct amdt p->pcm_channels = pcm_channels; - if (s->direction == AMDTP_IN_STREAM) - p->midi_ports = DOT_MIDI_IN_PORTS; - else - p->midi_ports = DOT_MIDI_OUT_PORTS; - /* * We do not know the actual MIDI FIFO size of most devices. Just * assume two bytes, i.e., one byte can be received over the bus while @@ -281,13 +277,25 @@ static void write_midi_messages(struct a b = (u8 *)&buffer[0]; len = 0; - if (port < p->midi_ports && + if (port < MAX_MIDI_PORTS && midi_ratelimit_per_packet(s, port) && p->midi[port] != NULL) len = snd_rawmidi_transmit(p->midi[port], b + 1, 2); if (len > 0) { - b[3] = (0x10 << port) | len; + /* + * Upper 4 bits of LSB represent port number. + * - 0000b: physical MIDI port 1. + * - 0010b: physical MIDI port 2. + * - 1110b: console MIDI port. + */ + if (port == 2) + b[3] = 0xe0; + else if (port == 1) + b[3] = 0x20; + else + b[3] = 0x00; + b[3] |= len; midi_use_bytes(s, port, len); } else { b[1] = 0; @@ -309,11 +317,22 @@ static void read_midi_messages(struct am for (f = 0; f < data_blocks; f++) { b = (u8 *)&buffer[0]; - port = b[3] >> 4; + len = b[3] & 0x0f; + if (len > 0) { + /* + * Upper 4 bits of LSB represent port number. + * - 0000b: physical MIDI port 1. Use port 0. + * - 1110b: console MIDI port. Use port 2. + */ + if (b[3] >> 4 > 0) + port = 2; + else + port = 0; - if (port < p->midi_ports && p->midi[port] && len > 0) - snd_rawmidi_receive(p->midi[port], b + 1, len); + if (port < MAX_MIDI_PORTS && p->midi[port]) + snd_rawmidi_receive(p->midi[port], b + 1, len); + } buffer += s->data_block_quadlets; } @@ -364,7 +383,7 @@ void amdtp_dot_midi_trigger(struct amdtp { struct amdtp_dot *p = s->protocol; - if (port < p->midi_ports) + if (port < MAX_MIDI_PORTS) ACCESS_ONCE(p->midi[port]) = midi; } Patches currently in stable-queue which might be from o-takashi(a)sakamocchi.jp are queue-4.4/alsa-firewire-digi00x-handle-all-midi-messages-on-streaming-packets.patch

7 years, 6 months

1
0
0 0

Patch "agp/intel: Flush all chipset writes after updating the GGTT" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled agp/intel: Flush all chipset writes after updating the GGTT to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: agp-intel-flush-all-chipset-writes-after-updating-the-ggtt.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Mar 19 09:58:12 CET 2018 From: Chris Wilson <chris(a)chris-wilson.co.uk> Date: Fri, 8 Dec 2017 21:46:16 +0000 Subject: agp/intel: Flush all chipset writes after updating the GGTT From: Chris Wilson <chris(a)chris-wilson.co.uk> [ Upstream commit 8516673a996870ea0ceb337ee4f83c33c5ec3111 ] Before accessing the GGTT we must flush the PTE writes and make them visible to the chipset, or else the indirect access may end up in the wrong page. In commit 3497971a71d8 ("agp/intel: Flush chipset writes after updating a single PTE"), we noticed corruption of the uploads for pwrite and for capturing GPU error states, but it was presumed that the explicit calls to intel_gtt_chipset_flush() were sufficient for the execbuffer path. However, we have not been flushing the chipset between the PTE writes and access via the GTT itself. For simplicity, do the flush after any PTE update rather than try and batch the flushes on a just-in-time basis. References: 3497971a71d8 ("agp/intel: Flush chipset writes after updating a single PTE") Signed-off-by: Chris Wilson <chris(a)chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin(a)intel.com> Cc: Mika Kuoppala <mika.kuoppala(a)intel.com> Cc: drm-intel-fixes(a)lists.freedesktop.org Reviewed-by: Joonas Lahtinen <joonas.lahtinen(a)linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171208214616.30147-1-chris@… Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/char/agp/intel-gtt.c | 2 ++ 1 file changed, 2 insertions(+) --- a/drivers/char/agp/intel-gtt.c +++ b/drivers/char/agp/intel-gtt.c @@ -859,6 +859,8 @@ void intel_gtt_insert_sg_entries(struct } } wmb(); + if (intel_private.driver->chipset_flush) + intel_private.driver->chipset_flush(); } EXPORT_SYMBOL(intel_gtt_insert_sg_entries); Patches currently in stable-queue which might be from chris(a)chris-wilson.co.uk are queue-4.4/drm-defer-disabling-the-vblank-irq-until-the-next-interrupt-for-instant-off.patch queue-4.4/agp-intel-flush-all-chipset-writes-after-updating-the-ggtt.patch

7 years, 6 months

1
0
0 0

Patch "powerpc/xmon: Fix an unexpected xmon on/off state change" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled powerpc/xmon: Fix an unexpected xmon on/off state change to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: powerpc-xmon-fix-an-unexpected-xmon-on-off-state-change.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Sun Mar 18 16:55:33 CET 2018 From: Pan Xinhui <xinhui.pan(a)linux.vnet.ibm.com> Date: Wed, 22 Mar 2017 16:27:49 -0300 Subject: powerpc/xmon: Fix an unexpected xmon on/off state change From: Pan Xinhui <xinhui.pan(a)linux.vnet.ibm.com> [ Upstream commit 3b5bf42b81d56085fd58692b5117f69aa77fdff7 ] Once xmon is triggered by sysrq-x, it is enabled always afterwards even if it is disabled during boot. This will cause a system reset interrupt fail to dump. So keep xmon in its original state after exit. We have several ways to set xmon on or off. 1) by a build config CONFIG_XMON_DEFAULT. 2) by a boot cmdline with xmon or xmon=early or xmon=on to enable xmon and xmon=off to disable xmon. This value will override that in step 1. 3) by a debugfs interface, as proposed in this patchset. And this value can override those in step 1 and 2. Signed-off-by: Pan Xinhui <xinhui.pan(a)linux.vnet.ibm.com> Signed-off-by: Guilherme G. Piccoli <gpiccoli(a)linux.vnet.ibm.com> Signed-off-by: Michael Ellerman <mpe(a)ellerman.id.au> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/powerpc/xmon/xmon.c | 17 ++++++++++------- 1 file changed, 10 insertions(+), 7 deletions(-) --- a/arch/powerpc/xmon/xmon.c +++ b/arch/powerpc/xmon/xmon.c @@ -74,6 +74,7 @@ static int xmon_gate; #endif /* CONFIG_SMP */ static unsigned long in_xmon __read_mostly = 0; +static int xmon_on = IS_ENABLED(CONFIG_XMON_DEFAULT); static unsigned long adrs; static int size = 1; @@ -3244,6 +3245,8 @@ static void sysrq_handle_xmon(int key) /* ensure xmon is enabled */ xmon_init(1); debugger(get_irq_regs()); + if (!xmon_on) + xmon_init(0); } static struct sysrq_key_op sysrq_xmon_op = { @@ -3260,7 +3263,7 @@ static int __init setup_xmon_sysrq(void) __initcall(setup_xmon_sysrq); #endif /* CONFIG_MAGIC_SYSRQ */ -static int __initdata xmon_early, xmon_off; +static int __initdata xmon_early; static int __init early_parse_xmon(char *p) { @@ -3268,10 +3271,12 @@ static int __init early_parse_xmon(char /* just "xmon" is equivalent to "xmon=early" */ xmon_init(1); xmon_early = 1; - } else if (strncmp(p, "on", 2) == 0) + xmon_on = 1; + } else if (strncmp(p, "on", 2) == 0) { xmon_init(1); - else if (strncmp(p, "off", 3) == 0) - xmon_off = 1; + xmon_on = 1; + } else if (strncmp(p, "off", 3) == 0) + xmon_on = 0; else if (strncmp(p, "nobt", 4) == 0) xmon_no_auto_backtrace = 1; else @@ -3283,10 +3288,8 @@ early_param("xmon", early_parse_xmon); void __init xmon_setup(void) { -#ifdef CONFIG_XMON_DEFAULT - if (!xmon_off) + if (xmon_on) xmon_init(1); -#endif if (xmon_early) debugger(NULL); } Patches currently in stable-queue which might be from xinhui.pan(a)linux.vnet.ibm.com are queue-4.9/powerpc-xmon-fix-an-unexpected-xmon-on-off-state-change.patch

7 years, 6 months

3
2
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror