This is a note to let you know that I've just added the patch titled
Revert "ARM: dts: imx53-qsb-common: fix FEC pinmux config"
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:
revert-arm-dts-imx53-qsb-common-fix-fec-pinmux-config.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 2cfe61144e9d770ed3e0556257e9dcc469ca14cf Mon Sep 17 00:00:00 2001
From: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Date: Thu, 16 Nov 2017 14:29:13 +0100
Subject: Revert "ARM: dts: imx53-qsb-common: fix FEC pinmux config"
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
This reverts commit 62b9fa2c436ffd9b87e6ed81df7f86c29fee092b which is
commit 8b649e426336d7d4800ff9c82858328f4215ba01 upstream.
Turns out not to be a good idea in the stable kernels for now as Patrick
writes:
As discussed for 4.4 stable queue this patch might break
existing machines, if they use a different pinmux configuration
with their own bootloader.
Reported-by: Patrick Brünn <P.Bruenn(a)beckhoff.com>
Cc: Shawn Guo <shawnguo(a)kernel.org>
Cc: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman gregkh(a)linuxfoundation.org
---
arch/arm/boot/dts/imx53-qsb-common.dtsi | 20 ++++++++++----------
1 file changed, 10 insertions(+), 10 deletions(-)
--- a/arch/arm/boot/dts/imx53-qsb-common.dtsi
+++ b/arch/arm/boot/dts/imx53-qsb-common.dtsi
@@ -215,16 +215,16 @@
pinctrl_fec: fecgrp {
fsl,pins = <
- MX53_PAD_FEC_MDC__FEC_MDC 0x4
- MX53_PAD_FEC_MDIO__FEC_MDIO 0x1fc
- MX53_PAD_FEC_REF_CLK__FEC_TX_CLK 0x180
- MX53_PAD_FEC_RX_ER__FEC_RX_ER 0x180
- MX53_PAD_FEC_CRS_DV__FEC_RX_DV 0x180
- MX53_PAD_FEC_RXD1__FEC_RDATA_1 0x180
- MX53_PAD_FEC_RXD0__FEC_RDATA_0 0x180
- MX53_PAD_FEC_TX_EN__FEC_TX_EN 0x4
- MX53_PAD_FEC_TXD1__FEC_TDATA_1 0x4
- MX53_PAD_FEC_TXD0__FEC_TDATA_0 0x4
+ MX53_PAD_FEC_MDC__FEC_MDC 0x80000000
+ MX53_PAD_FEC_MDIO__FEC_MDIO 0x80000000
+ MX53_PAD_FEC_REF_CLK__FEC_TX_CLK 0x80000000
+ MX53_PAD_FEC_RX_ER__FEC_RX_ER 0x80000000
+ MX53_PAD_FEC_CRS_DV__FEC_RX_DV 0x80000000
+ MX53_PAD_FEC_RXD1__FEC_RDATA_1 0x80000000
+ MX53_PAD_FEC_RXD0__FEC_RDATA_0 0x80000000
+ MX53_PAD_FEC_TX_EN__FEC_TX_EN 0x80000000
+ MX53_PAD_FEC_TXD1__FEC_TDATA_1 0x80000000
+ MX53_PAD_FEC_TXD0__FEC_TDATA_0 0x80000000
>;
};
Patches currently in stable-queue which might be from gregkh(a)linuxfoundation.org are
queue-4.9/net-call-cgroup_sk_alloc-earlier-in-sk_clone_lock.patch
queue-4.9/tcp-dccp-fix-ireq-opt-races.patch
queue-4.9/soreuseport-fix-initialization-race.patch
queue-4.9/tcp-fix-tcp_mtu_probe-vs-highest_sack.patch
queue-4.9/input-ims-psu-check-if-cdc-union-descriptor-is-sane.patch
queue-4.9/revert-arm-dts-imx53-qsb-common-fix-fec-pinmux-config.patch
queue-4.9/mac80211-use-constant-time-comparison-with-keys.patch
queue-4.9/ipv6-addrconf-increment-ifp-refcount-before-ipv6_del_addr.patch
queue-4.9/sctp-reset-owner-sk-for-data-chunks-on-out-queues-when-migrating-a-sock.patch
queue-4.9/ipip-only-increase-err_count-for-some-certain-type-icmp-in-ipip_err.patch
queue-4.9/ipv6-flowlabel-do-not-leave-opt-tot_len-with-garbage.patch
queue-4.9/sctp-full-support-for-ipv6-ip_nonlocal_bind-ip_freebind.patch
queue-4.9/packet-avoid-panic-in-packet_getsockopt.patch
queue-4.9/tun-call-dev_get_valid_name-before-register_netdevice.patch
queue-4.9/gso-fix-payload-length-when-gso_size-is-zero.patch
queue-4.9/sctp-add-the-missing-sock_owned_by_user-check-in-sctp_icmp_redirect.patch
queue-4.9/net_sched-avoid-matching-qdisc-with-zero-handle.patch
queue-4.9/ip6_gre-only-increase-err_count-for-some-certain-type-icmpv6-in-ip6gre_err.patch
queue-4.9/ip6_gre-update-dst-pmtu-if-dev-mtu-has-been-updated-by-toobig-in-__gre6_xmit.patch
queue-4.9/tun-tap-sanitize-tunsetsndbuf-input.patch
queue-4.9/alsa-seq-cancel-pending-autoload-work-at-unbinding-device.patch
queue-4.9/tap-double-free-in-error-path-in-tap_open.patch
queue-4.9/ppp-fix-race-in-ppp-device-destruction.patch
queue-4.9/tcp-dccp-fix-lockdep-splat-in-inet_csk_route_req.patch
queue-4.9/mac80211-don-t-compare-tkip-tx-mic-key-in-reinstall-prevention.patch
queue-4.9/l2tp-check-ps-sock-before-running-pppol2tp_session_ioctl.patch
queue-4.9/netlink-do-not-set-cb_running-if-dump-s-start-errs.patch
queue-4.9/tun-allow-positive-return-values-on-dev_get_valid_name-call.patch
queue-4.9/mac80211-accept-key-reinstall-without-changing-anything.patch
queue-4.9/usb-usbtest-fix-null-pointer-dereference.patch
queue-4.9/net-unix-don-t-show-information-about-sockets-from-other-namespaces.patch
queue-4.9/tcp-dccp-fix-other-lockdep-splats-accessing-ireq_opt.patch
This is a note to let you know that I've just added the patch titled
Revert "ARM: dts: imx53-qsb-common: fix FEC pinmux config"
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:
revert-arm-dts-imx53-qsb-common-fix-fec-pinmux-config.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 2cfe61144e9d770ed3e0556257e9dcc469ca14cf Mon Sep 17 00:00:00 2001
From: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Date: Thu, 16 Nov 2017 14:29:13 +0100
Subject: Revert "ARM: dts: imx53-qsb-common: fix FEC pinmux config"
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
This reverts commit 2eb85ef18c6570e8a59643cd8d5a66122461b1fc which is
commit 8b649e426336d7d4800ff9c82858328f4215ba01 upstream.
Turns out not to be a good idea in the stable kernels for now as Patrick
writes:
As discussed for 4.4 stable queue this patch might break
existing machines, if they use a different pinmux configuration
with their own bootloader.
Reported-by: Patrick Brünn <P.Bruenn(a)beckhoff.com>
Cc: Shawn Guo <shawnguo(a)kernel.org>
Cc: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman gregkh(a)linuxfoundation.org
---
arch/arm/boot/dts/imx53-qsb-common.dtsi | 20 ++++++++++----------
1 file changed, 10 insertions(+), 10 deletions(-)
--- a/arch/arm/boot/dts/imx53-qsb-common.dtsi
+++ b/arch/arm/boot/dts/imx53-qsb-common.dtsi
@@ -215,16 +215,16 @@
pinctrl_fec: fecgrp {
fsl,pins = <
- MX53_PAD_FEC_MDC__FEC_MDC 0x4
- MX53_PAD_FEC_MDIO__FEC_MDIO 0x1fc
- MX53_PAD_FEC_REF_CLK__FEC_TX_CLK 0x180
- MX53_PAD_FEC_RX_ER__FEC_RX_ER 0x180
- MX53_PAD_FEC_CRS_DV__FEC_RX_DV 0x180
- MX53_PAD_FEC_RXD1__FEC_RDATA_1 0x180
- MX53_PAD_FEC_RXD0__FEC_RDATA_0 0x180
- MX53_PAD_FEC_TX_EN__FEC_TX_EN 0x4
- MX53_PAD_FEC_TXD1__FEC_TDATA_1 0x4
- MX53_PAD_FEC_TXD0__FEC_TDATA_0 0x4
+ MX53_PAD_FEC_MDC__FEC_MDC 0x80000000
+ MX53_PAD_FEC_MDIO__FEC_MDIO 0x80000000
+ MX53_PAD_FEC_REF_CLK__FEC_TX_CLK 0x80000000
+ MX53_PAD_FEC_RX_ER__FEC_RX_ER 0x80000000
+ MX53_PAD_FEC_CRS_DV__FEC_RX_DV 0x80000000
+ MX53_PAD_FEC_RXD1__FEC_RDATA_1 0x80000000
+ MX53_PAD_FEC_RXD0__FEC_RDATA_0 0x80000000
+ MX53_PAD_FEC_TX_EN__FEC_TX_EN 0x80000000
+ MX53_PAD_FEC_TXD1__FEC_TDATA_1 0x80000000
+ MX53_PAD_FEC_TXD0__FEC_TDATA_0 0x80000000
>;
};
Patches currently in stable-queue which might be from gregkh(a)linuxfoundation.org are
queue-3.18/input-ims-psu-check-if-cdc-union-descriptor-is-sane.patch
queue-3.18/revert-arm-dts-imx53-qsb-common-fix-fec-pinmux-config.patch
queue-3.18/mac80211-use-constant-time-comparison-with-keys.patch
queue-3.18/revert-ceph-unlock-dangling-spinlock-in-try_flush_caps.patch
queue-3.18/mac80211-don-t-compare-tkip-tx-mic-key-in-reinstall-prevention.patch
queue-3.18/mac80211-accept-key-reinstall-without-changing-anything.patch
queue-3.18/usb-usbtest-fix-null-pointer-dereference.patch
Hi Aditya,
My problem is fixed with this patch. WILC1000 connects to AP,
IP is retrieved from DHCP server and ping works. You can add my
Tested-by: Claudiu Beznea <claudiu.beznea(a)microchip.com>
Thanks,
Claudiu
On 03.11.2017 10:56, Aditya Shankar wrote:
> Commit 46949b48568b ("staging: wilc1000: New cfg packet
> format in handle_set_wfi_drv_handler") updated the frame
> format sent from host to the firmware. The code to update
> the bssid offset in the new frame was part of a second
> patch in the series which did not make it in and thus
> causes connection problems after associating to an AP.
>
> This fix adds the proper offset of the bssid value in the
> Tx queue buffer to fix the connection issues.
>
> Fixes: Commit 46949b48568b ("staging: wilc1000: New cfg packet format in handle_set_wfi_drv_handler")
> Cc: stable(a)vger.kernel.org
> Signed-off-by: Aditya Shankar <Aditya.Shankar(a)microchip.com>
> ---
> drivers/staging/wilc1000/wilc_wlan.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/staging/wilc1000/wilc_wlan.c b/drivers/staging/wilc1000/wilc_wlan.c
> index 9addef1..f49dfa8 100644
> --- a/drivers/staging/wilc1000/wilc_wlan.c
> +++ b/drivers/staging/wilc1000/wilc_wlan.c
> @@ -714,7 +714,7 @@ int wilc_wlan_handle_txq(struct net_device *dev, u32 *txq_count)
> char *bssid = ((struct tx_complete_data *)(tqe->priv))->bssid;
>
> buffer_offset = ETH_ETHERNET_HDR_OFFSET;
> - memcpy(&txb[offset + 4], bssid, 6);
> + memcpy(&txb[offset + 8], bssid, 6);
> } else {
> buffer_offset = HOST_HDR_OFFSET;
> }
>
From: Nicholas Bellinger <nab(a)linux-iscsi.org>
Hi Greg-KH,
Here are three target patches for v3.10.y stable, the first of which
did not originally include a stable CC, and the latter two did not
apply due to a minor context change.
The series has been cut against v3.10.108. Please apply at your earliest
convenience.
Thank you,
--nab
Bart Van Assche (1):
target/iscsi: Fix iSCSI task reassignment handling
Mikulas Patocka (1):
iscsi-target: fix iscsit_del_np deadlock on unload
Nicholas Bellinger (1):
iscsi-target: Fix iscsi_np reset hung task during parallel delete
drivers/target/iscsi/iscsi_target.c | 20 ++++++++------------
drivers/target/iscsi/iscsi_target_core.h | 1 +
drivers/target/iscsi/iscsi_target_login.c | 25 ++++++++++++-------------
include/target/target_core_base.h | 1 +
4 files changed, 22 insertions(+), 25 deletions(-)
--
1.8.5.3
2017년 11월 01일 01:28에 Marek Szyprowski 이(가) 쓴 글:
> When no IOMMU is available, all GEM buffers allocated by Exynos DRM driver
> are contiguous, because of the underlying dma_alloc_attrs() function
> provides only such buffers. In such case it makes no sense to keep
What if user disabled CMA support? In this case, it guarantees also to allocate physically contiguous memory?
I think it depends on CMA support so wouldn't be true.
Real problem I think is that user don't know whether the gem buffer allocated with CONTIG or NONCONTIG flag can be used as a SCANOUT buffer.
So user can request a page flip with NONCONTIG buffer to kernel which doesn't support IOMMU.
And another is that user may want to use NONCONTIG buffer for another purpose, not scanout.
So if we enforce on using CONTIG buffer on kernel without IOMMU support, then it wouldn't be really what user intended.
My idea is to provide a new flag - i.e., EXYNOS_BO_SCANOUT - which can allocate a buffer with a different allocation type - CONTIG or NONCONTIG - according to IOMMU support.
And any page flip request with NONCONTIG buffer to kernel without IOMMU support should fail and it has to return a error with a proper error message.
> BO_NONCONTIG flag for the allocated GEM buffers. This allows to avoid
> failures for buffer contiguity checks in the subsequent operations on GEM
> objects.
>
> Signed-off-by: Marek Szyprowski <m.szyprowski(a)samsung.com>
> CC: stable(a)vger.kernel.org # v4.4+
> ---
> This issue is there since commit 0519f9a12d011 ("drm/exynos: add iommu
> support for exynos drm framework"), but this patch applies cleanly
> only to v4.4+ kernel releases due changes in the surrounding code.
> ---
> drivers/gpu/drm/exynos/exynos_drm_gem.c | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c b/drivers/gpu/drm/exynos/exynos_drm_gem.c
> index 02f978bb9261..476c00fe1998 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
> @@ -227,6 +227,13 @@ struct exynos_drm_gem *exynos_drm_gem_create(struct drm_device *dev,
> if (IS_ERR(exynos_gem))
> return exynos_gem;
>
> + /*
> + * when no IOMMU is available, all allocated buffers are contiguous
> + * anyway, so drop EXYNOS_BO_NONCONTIG flag
> + */
> + if (!is_drm_iommu_supported(dev))
> + flags &= ~EXYNOS_BO_NONCONTIG;
So this could be a tempararily solution until the new flag is added, and you may need to modify above comments.
Thanks,
Inki Dae
> +
> /* set memory type and cache attribute from user side. */
> exynos_gem->flags = flags;
>
>