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

Patch "batman-adv: handle race condition for claims between gateways" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled batman-adv: handle race condition for claims between gateways to the 3.18-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: batman-adv-handle-race-condition-for-claims-between-gateways.patch and it can be found in the queue-3.18 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 10:11:52 CET 2018 From: Andreas Pape <APape(a)phoenixcontact.com> Date: Mon, 5 Sep 2016 13:20:29 +0200 Subject: batman-adv: handle race condition for claims between gateways From: Andreas Pape <APape(a)phoenixcontact.com> [ Upstream commit a3a5129e122709306cfa6409781716c2933df99b ] Consider the following situation which has been found in a test setup: Gateway B has claimed client C and gateway A has the same backbone network as B. C sends a broad- or multicast to B and directly after this packet decides to send another packet to A due to a better TQ value. B will forward the broad-/multicast into the backbone as it is the responsible gw and after that A will claim C as it has been chosen by C as the best gateway. If it now happens that A claims C before it has received the broad-/multicast forwarded by B (due to backbone topology or due to some delay in B when forwarding the packet) we get a critical situation: in the current code A will immediately unclaim C when receiving the multicast due to the roaming client scenario although the position of C has not changed in the mesh. If this happens the multi-/broadcast forwarded by B will be sent back into the mesh by A and we have looping packets until one of the gateways claims C again. In order to prevent this, unclaiming of a client due to the roaming client scenario is only done after a certain time is expired after the last claim of the client. 100 ms are used here, which should be slow enough for big backbones and slow gateways but fast enough not to break the roaming client use case. Acked-by: Simon Wunderlich <sw(a)simonwunderlich.de> Signed-off-by: Andreas Pape <apape(a)phoenixcontact.com> [sven(a)narfation.org: fix conflicts with current version] Signed-off-by: Sven Eckelmann <sven(a)narfation.org> Signed-off-by: Simon Wunderlich <sw(a)simonwunderlich.de> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/batman-adv/bridge_loop_avoidance.c | 20 ++++++++++++++++---- 1 file changed, 16 insertions(+), 4 deletions(-) --- a/net/batman-adv/bridge_loop_avoidance.c +++ b/net/batman-adv/bridge_loop_avoidance.c @@ -1596,10 +1596,22 @@ int batadv_bla_tx(struct batadv_priv *ba /* if yes, the client has roamed and we have * to unclaim it. */ - batadv_handle_unclaim(bat_priv, primary_if, - primary_if->net_dev->dev_addr, - ethhdr->h_source, vid); - goto allow; + if (batadv_has_timed_out(claim->lasttime, 100)) { + /* only unclaim if the last claim entry is + * older than 100 ms to make sure we really + * have a roaming client here. + */ + batadv_dbg(BATADV_DBG_BLA, bat_priv, "bla_tx(): Roaming client %pM detected. Unclaim it.\n", + ethhdr->h_source); + batadv_handle_unclaim(bat_priv, primary_if, + primary_if->net_dev->dev_addr, + ethhdr->h_source, vid); + goto allow; + } else { + batadv_dbg(BATADV_DBG_BLA, bat_priv, "bla_tx(): Race for claim %pM detected. Drop packet.\n", + ethhdr->h_source); + goto handled; + } } /* check if it is a multicast/broadcast frame */ Patches currently in stable-queue which might be from APape(a)phoenixcontact.com are queue-3.18/batman-adv-handle-race-condition-for-claims-between-gateways.patch

7 years, 9 months

1
0
0 0

Patch "ath10k: disallow DFS simulation if DFS channel is not enabled" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ath10k: disallow DFS simulation if DFS channel is not enabled to the 3.18-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: ath10k-disallow-dfs-simulation-if-dfs-channel-is-not-enabled.patch and it can be found in the queue-3.18 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 10:11:52 CET 2018 From: Mohammed Shafi Shajakhan <mohammed(a)qti.qualcomm.com> Date: Wed, 22 Feb 2017 21:03:11 +0530 Subject: ath10k: disallow DFS simulation if DFS channel is not enabled From: Mohammed Shafi Shajakhan <mohammed(a)qti.qualcomm.com> [ Upstream commit ca07baab0b1e627ae1d4a55d190fb1c9d32a3445 ] If DFS is not enabled in hostapd (ieee80211h=0) DFS channels shall not be available for use even though the hardware may have the capability to support DFS. With this configuration (DFS disabled in hostapd) trying to bring up ath10k device in DFS channel for AP mode fails and trying to simulate DFS in ath10k debugfs results in a warning in cfg80211 complaining invalid channel and this should be avoided in the driver itself rather than false propogating RADAR detection to mac80211/cfg80211. Fix this by checking for the first vif 'is_started' state(should work for client mode as well) as all the vifs shall be configured for the same channel sys/kernel/debug/ieee80211/phy1/ath10k# echo 1 > dfs_simulate_radar WARNING: at net/wireless/chan.c:265 cfg80211_radar_event+0x24/0x60 Workqueue: phy0 ieee80211_dfs_radar_detected_work [mac80211] [<c022f2d4>] (warn_slowpath_null) from [<bf72dab8>] (cfg80211_radar_event+0x24/0x60 [cfg80211]) [<bf72dab8>] (cfg80211_radar_event [cfg80211]) from [<bf7813e0>] (ieee80211_dfs_radar_detected_work+0x94/0xa0 [mac80211]) [<bf7813e0>] (ieee80211_dfs_radar_detected_work [mac80211]) from [<c0242320>] (process_one_work+0x20c/0x32c) WARNING: at net/wireless/nl80211.c:2488 nl80211_get_mpath+0x13c/0x4cc Workqueue: phy0 ieee80211_dfs_radar_detected_work [mac80211] [<c022f2d4>] (warn_slowpath_null) from [<bf72dab8>] (cfg80211_radar_event+0x24/0x60 [cfg80211]) [<bf72dab8>] (cfg80211_radar_event [cfg80211]) from [<bf7813e0>] (ieee80211_dfs_radar_detected_work+0x94/0xa0 [mac80211]) [<bf7813e0>] (ieee80211_dfs_radar_detected_work [mac80211]) from [<c0242320>] (process_one_work+0x20c/0x32c) Signed-off-by: Mohammed Shafi Shajakhan <mohammed(a)qti.qualcomm.com> Signed-off-by: Kalle Valo <kvalo(a)qca.qualcomm.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/wireless/ath/ath10k/debug.c | 9 +++++++++ 1 file changed, 9 insertions(+) --- a/drivers/net/wireless/ath/ath10k/debug.c +++ b/drivers/net/wireless/ath/ath10k/debug.c @@ -1079,6 +1079,15 @@ static ssize_t ath10k_write_simulate_rad size_t count, loff_t *ppos) { struct ath10k *ar = file->private_data; + struct ath10k_vif *arvif; + + /* Just check for for the first vif alone, as all the vifs will be + * sharing the same channel and if the channel is disabled, all the + * vifs will share the same 'is_started' state. + */ + arvif = list_first_entry(&ar->arvifs, typeof(*arvif), list); + if (!arvif->is_started) + return -EINVAL; ieee80211_radar_detected(ar->hw); Patches currently in stable-queue which might be from mohammed(a)qti.qualcomm.com are queue-3.18/ath10k-disallow-dfs-simulation-if-dfs-channel-is-not-enabled.patch

7 years, 9 months

1
0
0 0

Patch "ASoC: nuc900: Fix a loop timeout test" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ASoC: nuc900: Fix a loop timeout test to the 3.18-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: asoc-nuc900-fix-a-loop-timeout-test.patch and it can be found in the queue-3.18 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 10:11:52 CET 2018 From: Dan Carpenter <dan.carpenter(a)oracle.com> Date: Sat, 9 Dec 2017 14:52:28 +0300 Subject: ASoC: nuc900: Fix a loop timeout test From: Dan Carpenter <dan.carpenter(a)oracle.com> [ Upstream commit 65a12b3aafed5fc59f4ce41b22b752b1729e6701 ] We should be finishing the loop with timeout set to zero but because this is a post-op we finish with timeout == -1. Fixes: 1082e2703a2d ("ASoC: NUC900/audio: add nuc900 audio driver support") Signed-off-by: Dan Carpenter <dan.carpenter(a)oracle.com> Signed-off-by: Mark Brown <broonie(a)kernel.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- sound/soc/nuc900/nuc900-ac97.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/sound/soc/nuc900/nuc900-ac97.c +++ b/sound/soc/nuc900/nuc900-ac97.c @@ -67,7 +67,7 @@ static unsigned short nuc900_ac97_read(s /* polling the AC_R_FINISH */ while (!(AUDIO_READ(nuc900_audio->mmio + ACTL_ACCON) & AC_R_FINISH) - && timeout--) + && --timeout) mdelay(1); if (!timeout) { @@ -121,7 +121,7 @@ static void nuc900_ac97_write(struct snd /* polling the AC_W_FINISH */ while ((AUDIO_READ(nuc900_audio->mmio + ACTL_ACCON) & AC_W_FINISH) - && timeout--) + && --timeout) mdelay(1); if (!timeout) Patches currently in stable-queue which might be from dan.carpenter(a)oracle.com are queue-3.18/media-cpia2-fix-a-couple-off-by-one-bugs.patch queue-3.18/asoc-nuc900-fix-a-loop-timeout-test.patch

7 years, 9 months

1
0
0 0

Patch "ARM: dts: r8a7790: Correct parent of SSI[0-9] clocks" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ARM: dts: r8a7790: Correct parent of SSI[0-9] clocks to the 3.18-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-r8a7790-correct-parent-of-ssi-clocks.patch and it can be found in the queue-3.18 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 10:11:52 CET 2018 From: Geert Uytterhoeven <geert+renesas(a)glider.be> Date: Mon, 3 Apr 2017 11:45:41 +0200 Subject: ARM: dts: r8a7790: Correct parent of SSI[0-9] clocks From: Geert Uytterhoeven <geert+renesas(a)glider.be> [ Upstream commit d13d4e063d4a08eb1686e890e9183dde709871bf ] The SSI-ALL gate clock is located in between the P clock and the individual SSI[0-9] clocks, hence the former should be listed as their parent. Fixes: bcde372254386872 ("ARM: shmobile: r8a7790: add MSTP10 support on DTSI") Signed-off-by: Geert Uytterhoeven <geert+renesas(a)glider.be> 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/r8a7790.dtsi | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) --- a/arch/arm/boot/dts/r8a7790.dtsi +++ b/arch/arm/boot/dts/r8a7790.dtsi @@ -978,8 +978,11 @@ compatible = "renesas,r8a7790-mstp-clocks", "renesas,cpg-mstp-clocks"; reg = <0 0xe6150998 0 4>, <0 0xe61509a8 0 4>; clocks = <&p_clk>, - <&p_clk>, <&p_clk>, <&p_clk>, <&p_clk>, <&p_clk>, - <&p_clk>, <&p_clk>, <&p_clk>, <&p_clk>, <&p_clk>, + <&mstp10_clks R8A7790_CLK_SSI_ALL>, <&mstp10_clks R8A7790_CLK_SSI_ALL>, + <&mstp10_clks R8A7790_CLK_SSI_ALL>, <&mstp10_clks R8A7790_CLK_SSI_ALL>, + <&mstp10_clks R8A7790_CLK_SSI_ALL>, <&mstp10_clks R8A7790_CLK_SSI_ALL>, + <&mstp10_clks R8A7790_CLK_SSI_ALL>, <&mstp10_clks R8A7790_CLK_SSI_ALL>, + <&mstp10_clks R8A7790_CLK_SSI_ALL>, <&mstp10_clks R8A7790_CLK_SSI_ALL>, <&p_clk>, <&mstp10_clks R8A7790_CLK_SCU_ALL>, <&mstp10_clks R8A7790_CLK_SCU_ALL>, <&mstp10_clks R8A7790_CLK_SCU_ALL>, <&mstp10_clks R8A7790_CLK_SCU_ALL>, Patches currently in stable-queue which might be from geert+renesas(a)glider.be are queue-3.18/arm-dts-r8a7791-correct-parent-of-ssi-clocks.patch queue-3.18/arm-dts-r8a7790-correct-parent-of-ssi-clocks.patch

7 years, 9 months

1
0
0 0

Patch "ARM: dts: r8a7791: Correct parent of SSI[0-9] clocks" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ARM: dts: r8a7791: Correct parent of SSI[0-9] clocks to the 3.18-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-r8a7791-correct-parent-of-ssi-clocks.patch and it can be found in the queue-3.18 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 10:11:52 CET 2018 From: Geert Uytterhoeven <geert+renesas(a)glider.be> Date: Mon, 3 Apr 2017 11:45:42 +0200 Subject: ARM: dts: r8a7791: Correct parent of SSI[0-9] clocks From: Geert Uytterhoeven <geert+renesas(a)glider.be> [ Upstream commit 16fe68dcab5702a024d85229ff7e98979cb701a5 ] The SSI-ALL gate clock is located in between the P clock and the individual SSI[0-9] clocks, hence the former should be listed as their parent. Fixes: ee9141522dcf13f8 ("ARM: shmobile: r8a7791: add MSTP10 support on DTSI") Signed-off-by: Geert Uytterhoeven <geert+renesas(a)glider.be> 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.dtsi | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) --- a/arch/arm/boot/dts/r8a7791.dtsi +++ b/arch/arm/boot/dts/r8a7791.dtsi @@ -1001,8 +1001,11 @@ compatible = "renesas,r8a7791-mstp-clocks", "renesas,cpg-mstp-clocks"; reg = <0 0xe6150998 0 4>, <0 0xe61509a8 0 4>; clocks = <&p_clk>, - <&p_clk>, <&p_clk>, <&p_clk>, <&p_clk>, <&p_clk>, - <&p_clk>, <&p_clk>, <&p_clk>, <&p_clk>, <&p_clk>, + <&mstp10_clks R8A7791_CLK_SSI_ALL>, <&mstp10_clks R8A7791_CLK_SSI_ALL>, + <&mstp10_clks R8A7791_CLK_SSI_ALL>, <&mstp10_clks R8A7791_CLK_SSI_ALL>, + <&mstp10_clks R8A7791_CLK_SSI_ALL>, <&mstp10_clks R8A7791_CLK_SSI_ALL>, + <&mstp10_clks R8A7791_CLK_SSI_ALL>, <&mstp10_clks R8A7791_CLK_SSI_ALL>, + <&mstp10_clks R8A7791_CLK_SSI_ALL>, <&mstp10_clks R8A7791_CLK_SSI_ALL>, <&p_clk>, <&mstp10_clks R8A7791_CLK_SCU_ALL>, <&mstp10_clks R8A7791_CLK_SCU_ALL>, <&mstp10_clks R8A7791_CLK_SCU_ALL>, <&mstp10_clks R8A7791_CLK_SCU_ALL>, Patches currently in stable-queue which might be from geert+renesas(a)glider.be are queue-3.18/arm-dts-r8a7791-correct-parent-of-ssi-clocks.patch queue-3.18/arm-dts-r8a7790-correct-parent-of-ssi-clocks.patch

7 years, 9 months

1
0
0 0

Patch "ARM: dts: am335x-pepper: Fix the audio CODEC's reset pin" has been added to the 3.18-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 3.18-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-3.18 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 10:11:52 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 @@ -138,7 +138,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-3.18/arm-dts-omap3-n900-fix-the-audio-codec-s-reset-pin.patch queue-3.18/arm-dts-am335x-pepper-fix-the-audio-codec-s-reset-pin.patch

7 years, 9 months

1
0
0 0

Patch "ARM: dts: omap3-n900: Fix the audio CODEC's reset pin" has been added to the 3.18-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 3.18-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-3.18 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 10:11:52 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 @@ -435,7 +435,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 */ @@ -452,7 +452,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-3.18/arm-dts-omap3-n900-fix-the-audio-codec-s-reset-pin.patch queue-3.18/arm-dts-am335x-pepper-fix-the-audio-codec-s-reset-pin.patch

7 years, 9 months

1
0
0 0

Patch "ARM: dts: Adjust moxart IRQ controller and flags" has been added to the 3.18-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 3.18-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-3.18 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 10:11:52 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-3.18/arm-dts-adjust-moxart-irq-controller-and-flags.patch

7 years, 9 months

1
0
0 0

Patch "ARM: DRA7: hwmod_data: Prevent wait_target_disable error for usb_otg_ss" has been added to the 3.18-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 3.18-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-3.18 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 10:11:52 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 @@ -2106,6 +2106,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, @@ -2127,6 +2128,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-3.18/arm-dra7-hwmod_data-prevent-wait_target_disable-error-for-usb_otg_ss.patch

7 years, 9 months

1
0
0 0

Patch "apparmor: Make path_max parameter readonly" has been added to the 3.18-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 3.18-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-3.18 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 10:11:52 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 @@ -735,7 +735,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-3.18/apparmor-make-path_max-parameter-readonly.patch

7 years, 9 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror