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

Patch "video/hdmi: Allow "empty" HDMI infoframes" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled video/hdmi: Allow "empty" HDMI infoframes to the 4.15-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: video-hdmi-allow-empty-hdmi-infoframes.patch and it can be found in the queue-4.15 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 Fri Mar 16 15:11:07 CET 2018 From: "Ville Syrjälä" <ville.syrjala(a)linux.intel.com> Date: Mon, 13 Nov 2017 19:04:18 +0200 Subject: video/hdmi: Allow "empty" HDMI infoframes From: "Ville Syrjälä" <ville.syrjala(a)linux.intel.com> [ Upstream commit 593f4b19a094c4426bd1e1e3cbab87a48bd13c71 ] HDMI 2.0 Appendix F suggest that we should keep sending the infoframe when switching from 3D to 2D mode, even if the infoframe isn't strictly necessary (ie. not needed to transmit the VIC or stereo information). This is a workaround against some sinks that fail to realize that they should switch from 3D to 2D mode when the source stop transmitting the infoframe. v2: Handle unpack() as well Pull the length calculation into a helper Cc: Shashank Sharma <shashank.sharma(a)intel.com> Cc: Andrzej Hajda <a.hajda(a)samsung.com> Cc: Thierry Reding <thierry.reding(a)gmail.com> Cc: Hans Verkuil <hans.verkuil(a)cisco.com> Cc: linux-media(a)vger.kernel.org Reviewed-by: Andrzej Hajda <a.hajda(a)samsung.com> #v1 Signed-off-by: Ville SyrjÃ¤lÃ¤ <ville.syrjala(a)linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171113170427.4150-2-ville.s… Reviewed-by: Shashank Sharma <shashank.sharma(a)intel.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/video/hdmi.c | 51 +++++++++++++++++++++++++++++++-------------------- 1 file changed, 31 insertions(+), 20 deletions(-) --- a/drivers/video/hdmi.c +++ b/drivers/video/hdmi.c @@ -321,6 +321,17 @@ int hdmi_vendor_infoframe_init(struct hd } EXPORT_SYMBOL(hdmi_vendor_infoframe_init); +static int hdmi_vendor_infoframe_length(const struct hdmi_vendor_infoframe *frame) +{ + /* for side by side (half) we also need to provide 3D_Ext_Data */ + if (frame->s3d_struct >= HDMI_3D_STRUCTURE_SIDE_BY_SIDE_HALF) + return 6; + else if (frame->vic != 0 || frame->s3d_struct != HDMI_3D_STRUCTURE_INVALID) + return 5; + else + return 4; +} + /** * hdmi_vendor_infoframe_pack() - write a HDMI vendor infoframe to binary buffer * @frame: HDMI infoframe @@ -341,19 +352,11 @@ ssize_t hdmi_vendor_infoframe_pack(struc u8 *ptr = buffer; size_t length; - /* empty info frame */ - if (frame->vic == 0 && frame->s3d_struct == HDMI_3D_STRUCTURE_INVALID) - return -EINVAL; - /* only one of those can be supplied */ if (frame->vic != 0 && frame->s3d_struct != HDMI_3D_STRUCTURE_INVALID) return -EINVAL; - /* for side by side (half) we also need to provide 3D_Ext_Data */ - if (frame->s3d_struct >= HDMI_3D_STRUCTURE_SIDE_BY_SIDE_HALF) - frame->length = 6; - else - frame->length = 5; + frame->length = hdmi_vendor_infoframe_length(frame); length = HDMI_INFOFRAME_HEADER_SIZE + frame->length; @@ -372,14 +375,16 @@ ssize_t hdmi_vendor_infoframe_pack(struc ptr[5] = 0x0c; ptr[6] = 0x00; - if (frame->vic) { - ptr[7] = 0x1 << 5; /* video format */ - ptr[8] = frame->vic; - } else { + if (frame->s3d_struct != HDMI_3D_STRUCTURE_INVALID) { ptr[7] = 0x2 << 5; /* video format */ ptr[8] = (frame->s3d_struct & 0xf) << 4; if (frame->s3d_struct >= HDMI_3D_STRUCTURE_SIDE_BY_SIDE_HALF) ptr[9] = (frame->s3d_ext_data & 0xf) << 4; + } else if (frame->vic) { + ptr[7] = 0x1 << 5; /* video format */ + ptr[8] = frame->vic; + } else { + ptr[7] = 0x0 << 5; /* video format */ } hdmi_infoframe_set_checksum(buffer, length); @@ -1165,7 +1170,7 @@ hdmi_vendor_any_infoframe_unpack(union h if (ptr[0] != HDMI_INFOFRAME_TYPE_VENDOR || ptr[1] != 1 || - (ptr[2] != 5 && ptr[2] != 6)) + (ptr[2] != 4 && ptr[2] != 5 && ptr[2] != 6)) return -EINVAL; length = ptr[2]; @@ -1193,16 +1198,22 @@ hdmi_vendor_any_infoframe_unpack(union h hvf->length = length; - if (hdmi_video_format == 0x1) { - hvf->vic = ptr[4]; - } else if (hdmi_video_format == 0x2) { + if (hdmi_video_format == 0x2) { + if (length != 5 && length != 6) + return -EINVAL; hvf->s3d_struct = ptr[4] >> 4; if (hvf->s3d_struct >= HDMI_3D_STRUCTURE_SIDE_BY_SIDE_HALF) { - if (length == 6) - hvf->s3d_ext_data = ptr[5] >> 4; - else + if (length != 6) return -EINVAL; + hvf->s3d_ext_data = ptr[5] >> 4; } + } else if (hdmi_video_format == 0x1) { + if (length != 5) + return -EINVAL; + hvf->vic = ptr[4]; + } else { + if (length != 4) + return -EINVAL; } return 0; Patches currently in stable-queue which might be from ville.syrjala(a)linux.intel.com are queue-4.15/drm-vblank-fix-vblank-timestamp-debugs.patch queue-4.15/video-hdmi-allow-empty-hdmi-infoframes.patch queue-4.15/drm-edid-set-eld-connector-type-in-drm_edid_to_eld.patch

7 years, 4 months

1
0
0 0

Patch "veth: set peer GSO values" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled veth: set peer GSO values to the 4.15-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: veth-set-peer-gso-values.patch and it can be found in the queue-4.15 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 Fri Mar 16 15:11:08 CET 2018 From: Stephen Hemminger <stephen(a)networkplumber.org> Date: Thu, 7 Dec 2017 15:40:20 -0800 Subject: veth: set peer GSO values From: Stephen Hemminger <stephen(a)networkplumber.org> [ Upstream commit 72d24955b44a4039db54a1c252b5031969eeaac3 ] When new veth is created, and GSO values have been configured on one device, clone those values to the peer. For example: # ip link add dev vm1 gso_max_size 65530 type veth peer name vm2 This should create vm1 <--> vm2 with both having GSO maximum size set to 65530. Signed-off-by: Stephen Hemminger <sthemmin(a)microsoft.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/veth.c | 3 +++ 1 file changed, 3 insertions(+) --- a/drivers/net/veth.c +++ b/drivers/net/veth.c @@ -410,6 +410,9 @@ static int veth_newlink(struct net *src_ if (ifmp && (dev->ifindex != 0)) peer->ifindex = ifmp->ifi_index; + peer->gso_max_size = dev->gso_max_size; + peer->gso_max_segs = dev->gso_max_segs; + err = register_netdevice(peer); put_net(net); net = NULL; Patches currently in stable-queue which might be from stephen(a)networkplumber.org are queue-4.15/veth-set-peer-gso-values.patch

7 years, 4 months

1
0
0 0

Patch "userns: Don't fail follow_automount based on s_user_ns" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled userns: Don't fail follow_automount based on s_user_ns to the 4.15-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: userns-don-t-fail-follow_automount-based-on-s_user_ns.patch and it can be found in the queue-4.15 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 Fri Mar 16 15:11:07 CET 2018 From: "Eric W. Biederman" <ebiederm(a)xmission.com> Date: Wed, 29 Nov 2017 17:29:20 -0600 Subject: userns: Don't fail follow_automount based on s_user_ns From: "Eric W. Biederman" <ebiederm(a)xmission.com> [ Upstream commit bbc3e471011417598e598707486f5d8814ec9c01 ] When vfs_submount was added the test to limit automounts from filesystems that with s_user_ns != &init_user_ns accidentially left in follow_automount. The test was never about any security concerns and was always about how do we implement this for filesystems whose s_user_ns != &init_user_ns. At the moment this check makes no difference as there are no filesystems that both set FS_USERNS_MOUNT and implement d_automount. Remove this check now while I am thinking about it so there will not be odd booby traps for someone who does want to make this combination work. vfs_submount still needs improvements to allow this combination to work, and vfs_submount contains a check that presents a warning. The autofs4 filesystem could be modified to set FS_USERNS_MOUNT and it would need not work on this code path, as userspace performs the mounts. Fixes: 93faccbbfa95 ("fs: Better permission checking for submounts") Fixes: aeaa4a79ff6a ("fs: Call d_automount with the filesystems creds") Acked-by: Ian Kent <raven(a)themaw.net> Signed-off-by: "Eric W. Biederman" <ebiederm(a)xmission.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/namei.c | 3 --- 1 file changed, 3 deletions(-) --- a/fs/namei.c +++ b/fs/namei.c @@ -1133,9 +1133,6 @@ static int follow_automount(struct path path->dentry->d_inode) return -EISDIR; - if (path->dentry->d_sb->s_user_ns != &init_user_ns) - return -EACCES; - nd->total_link_count++; if (nd->total_link_count >= 40) return -ELOOP; Patches currently in stable-queue which might be from ebiederm(a)xmission.com are queue-4.15/userns-don-t-fail-follow_automount-based-on-s_user_ns.patch

7 years, 4 months

1
0
0 0

Patch "USB: ledtrig-usbport: fix of-node leak" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled USB: ledtrig-usbport: fix of-node leak to the 4.15-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: usb-ledtrig-usbport-fix-of-node-leak.patch and it can be found in the queue-4.15 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 Fri Mar 16 15:11:07 CET 2018 From: Johan Hovold <johan(a)kernel.org> Date: Thu, 9 Nov 2017 18:07:22 +0100 Subject: USB: ledtrig-usbport: fix of-node leak From: Johan Hovold <johan(a)kernel.org> [ Upstream commit 03310a15484ab6a8f6d91bbf7fe486b17275c09a ] This code looks up a USB device node from a given parent USB device but never dropped its reference to the returned node. As only the address of the node is used for a later matching, the reference can be dropped immediately. Note that this trigger implementation confuses the description of the USB device connected to a port with the port itself (which does not have a device-tree representation). Fixes: 4f04c210d031 ("usb: core: read USB ports from DT in the usbport LED trigger driver") Cc: Rafał Miłecki <rafal(a)milecki.pl> Signed-off-by: Johan Hovold <johan(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/usb/core/ledtrig-usbport.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) --- a/drivers/usb/core/ledtrig-usbport.c +++ b/drivers/usb/core/ledtrig-usbport.c @@ -137,11 +137,17 @@ static bool usbport_trig_port_observed(s if (!led_np) return false; - /* Get node of port being added */ + /* + * Get node of port being added + * + * FIXME: This is really the device node of the connected device + */ port_np = usb_of_get_child_node(usb_dev->dev.of_node, port1); if (!port_np) return false; + of_node_put(port_np); + /* Amount of trigger sources for this LED */ count = of_count_phandle_with_args(led_np, "trigger-sources", "#trigger-source-cells"); Patches currently in stable-queue which might be from johan(a)kernel.org are queue-4.15/usb-ledtrig-usbport-fix-of-node-leak.patch queue-4.15/serial-core-mark-port-as-initialized-in-autoconfig.patch

7 years, 4 months

1
0
0 0

Patch "typec: tcpm: fusb302: Resolve out of order messaging events" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled typec: tcpm: fusb302: Resolve out of order messaging events to the 4.15-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: typec-tcpm-fusb302-resolve-out-of-order-messaging-events.patch and it can be found in the queue-4.15 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 Fri Mar 16 15:11:07 CET 2018 From: Adam Thomson <Adam.Thomson.Opensource(a)diasemi.com> Date: Tue, 21 Nov 2017 14:12:12 +0000 Subject: typec: tcpm: fusb302: Resolve out of order messaging events From: Adam Thomson <Adam.Thomson.Opensource(a)diasemi.com> [ Upstream commit ab69f61321140ff632d560775bc226259a78dfa2 ] The expectation in the FUSB302 driver is that a TX_SUCCESS event should occur after a message has been sent, but before a GCRCSENT event is raised to indicate successful receipt of a message from the partner. However in some circumstances it is possible to see the hardware raise a GCRCSENT event before a TX_SUCCESS event is raised. The upshot of this is that the GCRCSENT handling portion of code ends up reporting the GoodCRC message to TCPM because the TX_SUCCESS event hasn't yet arrived to trigger a consumption of it. When TX_SUCCESS is then raised by the chip it ends up consuming the actual message that was meant for TCPM, and this incorrect sequence results in a hard reset from TCPM. To avoid this problem, this commit updates the message reading code to check whether a GoodCRC message was received or not. Based on this check it will either report that the previous transmission has completed or it will pass the msg data to TCPM for futher processing. This way the incorrect ordering of the events no longer matters. Signed-off-by: Adam Thomson <Adam.Thomson.Opensource(a)diasemi.com> Reviewed-by: Guenter Roeck <linux(a)roeck-us.net> Acked-by: Heikki Krogerus <heikki.krogerus(a)linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/usb/typec/fusb302/fusb302.c | 21 +++++++++++++++++---- 1 file changed, 17 insertions(+), 4 deletions(-) --- a/drivers/usb/typec/fusb302/fusb302.c +++ b/drivers/usb/typec/fusb302/fusb302.c @@ -1543,6 +1543,21 @@ static int fusb302_pd_read_message(struc fusb302_log(chip, "PD message header: %x", msg->header); fusb302_log(chip, "PD message len: %d", len); + /* + * Check if we've read off a GoodCRC message. If so then indicate to + * TCPM that the previous transmission has completed. Otherwise we pass + * the received message over to TCPM for processing. + * + * We make this check here instead of basing the reporting decision on + * the IRQ event type, as it's possible for the chip to report the + * TX_SUCCESS and GCRCSENT events out of order on occasion, so we need + * to check the message type to ensure correct reporting to TCPM. + */ + if ((!len) && (pd_header_type_le(msg->header) == PD_CTRL_GOOD_CRC)) + tcpm_pd_transmit_complete(chip->tcpm_port, TCPC_TX_SUCCESS); + else + tcpm_pd_receive(chip->tcpm_port, msg); + return ret; } @@ -1650,13 +1665,12 @@ static irqreturn_t fusb302_irq_intn(int if (interrupta & FUSB_REG_INTERRUPTA_TX_SUCCESS) { fusb302_log(chip, "IRQ: PD tx success"); - /* read out the received good CRC */ ret = fusb302_pd_read_message(chip, &pd_msg); if (ret < 0) { - fusb302_log(chip, "cannot read in GCRC, ret=%d", ret); + fusb302_log(chip, + "cannot read in PD message, ret=%d", ret); goto done; } - tcpm_pd_transmit_complete(chip->tcpm_port, TCPC_TX_SUCCESS); } if (interrupta & FUSB_REG_INTERRUPTA_HARDRESET) { @@ -1677,7 +1691,6 @@ static irqreturn_t fusb302_irq_intn(int "cannot read in PD message, ret=%d", ret); goto done; } - tcpm_pd_receive(chip->tcpm_port, &pd_msg); } done: mutex_unlock(&chip->lock); Patches currently in stable-queue which might be from Adam.Thomson.Opensource(a)diasemi.com are queue-4.15/typec-tcpm-fusb302-resolve-out-of-order-messaging-events.patch

7 years, 4 months

1
0
0 0

Patch "tools/usbip: fixes build with musl libc toolchain" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled tools/usbip: fixes build with musl libc toolchain to the 4.15-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: tools-usbip-fixes-build-with-musl-libc-toolchain.patch and it can be found in the queue-4.15 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 Fri Mar 16 15:11:08 CET 2018 From: Julien BOIBESSOT <julien.boibessot(a)armadeus.com> Date: Tue, 5 Dec 2017 18:48:14 +0100 Subject: tools/usbip: fixes build with musl libc toolchain From: Julien BOIBESSOT <julien.boibessot(a)armadeus.com> [ Upstream commit 77be4c878c72e411ad22af96b6f81dd45c26450a ] Indeed musl doesn't define old SIGCLD signal name but only new one SIGCHLD. SIGCHLD is the new POSIX name for that signal so it doesn't change anything on other libcs. This fixes this kind of build error: usbipd.c: In function ‘set_signal’: usbipd.c:459:12: error: 'SIGCLD' undeclared (first use in this function) sigaction(SIGCLD, &act, NULL); ^~~~~~ usbipd.c:459:12: note: each undeclared identifier is reported only once for each function it appears in Makefile:407: recipe for target 'usbipd.o' failed make[3]: *** [usbipd.o] Error 1 Signed-off-by: Julien BOIBESSOT <julien.boibessot(a)armadeus.com> Acked-by: Shuah Khan <shuahkh(a)osg.samsung.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- tools/usb/usbip/src/usbipd.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/tools/usb/usbip/src/usbipd.c +++ b/tools/usb/usbip/src/usbipd.c @@ -456,7 +456,7 @@ static void set_signal(void) sigaction(SIGTERM, &act, NULL); sigaction(SIGINT, &act, NULL); act.sa_handler = SIG_IGN; - sigaction(SIGCLD, &act, NULL); + sigaction(SIGCHLD, &act, NULL); } static const char *pid_file; Patches currently in stable-queue which might be from julien.boibessot(a)armadeus.com are queue-4.15/tools-usbip-fixes-build-with-musl-libc-toolchain.patch

7 years, 4 months

1
0
0 0

Patch "test_firmware: fix setting old custom fw path back on exit" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled test_firmware: fix setting old custom fw path back on exit to the 4.15-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: test_firmware-fix-setting-old-custom-fw-path-back-on-exit.patch and it can be found in the queue-4.15 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 Fri Mar 16 15:11:07 CET 2018 From: "Luis R. Rodriguez" <mcgrof(a)kernel.org> Date: Mon, 20 Nov 2017 09:45:35 -0800 Subject: test_firmware: fix setting old custom fw path back on exit From: "Luis R. Rodriguez" <mcgrof(a)kernel.org> [ Upstream commit 65c79230576873b312c3599479c1e42355c9f349 ] The file /sys/module/firmware_class/parameters/path can be used to set a custom firmware path. The fw_filesystem.sh script creates a temporary directory to add a test firmware file to be used during testing, in order for this to work it uses the custom path syfs file and it was supposed to reset back the file on execution exit. The script failed to do this due to a typo, it was using OLD_PATH instead of OLD_FWPATH, since its inception since v3.17. Its not as easy to just keep the old setting, it turns out that resetting an empty setting won't actually do what we want, we need to check if it was empty and set an empty space. Without this we end up having the temporary path always set after we run these tests. Fixes: 0a8adf58475 ("test: add firmware_class loader test") Signed-off-by: Luis R. Rodriguez <mcgrof(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- tools/testing/selftests/firmware/fw_filesystem.sh | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) --- a/tools/testing/selftests/firmware/fw_filesystem.sh +++ b/tools/testing/selftests/firmware/fw_filesystem.sh @@ -45,7 +45,10 @@ test_finish() if [ "$HAS_FW_LOADER_USER_HELPER" = "yes" ]; then echo "$OLD_TIMEOUT" >/sys/class/firmware/timeout fi - echo -n "$OLD_PATH" >/sys/module/firmware_class/parameters/path + if [ "$OLD_FWPATH" = "" ]; then + OLD_FWPATH=" " + fi + echo -n "$OLD_FWPATH" >/sys/module/firmware_class/parameters/path rm -f "$FW" rmdir "$FWPATH" } Patches currently in stable-queue which might be from mcgrof(a)kernel.org are queue-4.15/test_firmware-fix-setting-old-custom-fw-path-back-on-exit.patch

7 years, 4 months

1
0
0 0

Patch "staging: rtl8822be: fix missing null check on dev_alloc_skb return" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled staging: rtl8822be: fix missing null check on dev_alloc_skb return to the 4.15-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: staging-rtl8822be-fix-missing-null-check-on-dev_alloc_skb-return.patch and it can be found in the queue-4.15 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 Fri Mar 16 15:11:07 CET 2018 From: Colin Ian King <colin.king(a)canonical.com> Date: Fri, 17 Nov 2017 14:50:55 +0000 Subject: staging: rtl8822be: fix missing null check on dev_alloc_skb return From: Colin Ian King <colin.king(a)canonical.com> [ Upstream commit 3eb23426e1749a0483bc4c9b18e51f657569e3ed ] dev_alloc_skb can potentially return NULL, so add a null check to avoid a null pointer dereference on skb Detected by CoverityScan, CID#1454558 ("Dereference on null return") Fixes: 7e5b796cde7e ("staging: r8822be: Add the driver code") Signed-off-by: Colin Ian King <colin.king(a)canonical.com> Acked-by: Larry Finger <Larry.Finger(a)lwfinger.net> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/staging/rtlwifi/rtl8822be/fw.c | 2 ++ 1 file changed, 2 insertions(+) --- a/drivers/staging/rtlwifi/rtl8822be/fw.c +++ b/drivers/staging/rtlwifi/rtl8822be/fw.c @@ -464,6 +464,8 @@ bool rtl8822b_halmac_cb_write_data_rsvd_ int count; skb = dev_alloc_skb(size); + if (!skb) + return false; memcpy((u8 *)skb_put(skb, size), buf, size); if (!_rtl8822be_send_bcn_or_cmd_packet(rtlpriv->hw, skb, BEACON_QUEUE)) Patches currently in stable-queue which might be from colin.king(a)canonical.com are queue-4.15/usbip-vudc-fix-null-pointer-dereference-on-udc-lock.patch queue-4.15/crypto-cavium-fix-memory-leak-on-info.patch queue-4.15/staging-rtl8822be-fix-missing-null-check-on-dev_alloc_skb-return.patch

7 years, 4 months

1
0
0 0

Patch "staging: fsl-dpaa2/eth: Fix access to FAS field" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled staging: fsl-dpaa2/eth: Fix access to FAS field to the 4.15-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: staging-fsl-dpaa2-eth-fix-access-to-fas-field.patch and it can be found in the queue-4.15 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 Fri Mar 16 15:11:08 CET 2018 From: Ioana Radulescu <ruxandra.radulescu(a)nxp.com> Date: Fri, 8 Dec 2017 06:47:53 -0600 Subject: staging: fsl-dpaa2/eth: Fix access to FAS field From: Ioana Radulescu <ruxandra.radulescu(a)nxp.com> [ Upstream commit 54ce891779888e85a2db04942dbaadd3f40fe223 ] Commit 4b2d9fe87950 ("staging: fsl-dpaa2/eth: Extra headroom in RX buffers") removes the software annotation (SWA) area from the RX buffer layout, as it's not used by anyone, but fails to update the macros for accessing hardware annotation (HWA) fields, which is right after the SWA in the buffer headroom. This may lead to some frame annotation status fields (e.g. indication if L3/L4 checksum is valid) to be read incorrectly. Turn the accessor macros into inline functions and add a bool param to specify if SWA is present or not. Fixes: 4b2d9fe87950 ("staging: fsl-dpaa2/eth: Extra headroom in RX buffers") Signed-off-by: Ioana Radulescu <ruxandra.radulescu(a)nxp.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/staging/fsl-dpaa2/ethernet/dpaa2-eth.c | 8 ++++---- drivers/staging/fsl-dpaa2/ethernet/dpaa2-eth.h | 13 +++++++++---- 2 files changed, 13 insertions(+), 8 deletions(-) --- a/drivers/staging/fsl-dpaa2/ethernet/dpaa2-eth.c +++ b/drivers/staging/fsl-dpaa2/ethernet/dpaa2-eth.c @@ -249,7 +249,7 @@ static void dpaa2_eth_rx(struct dpaa2_et vaddr = dpaa2_iova_to_virt(priv->iommu_domain, addr); dma_unmap_single(dev, addr, DPAA2_ETH_RX_BUF_SIZE, DMA_FROM_DEVICE); - fas = dpaa2_get_fas(vaddr); + fas = dpaa2_get_fas(vaddr, false); prefetch(fas); buf_data = vaddr + dpaa2_fd_get_offset(fd); prefetch(buf_data); @@ -385,7 +385,7 @@ static int build_sg_fd(struct dpaa2_eth_ * on TX confirmation. We are clearing FAS (Frame Annotation Status) * field from the hardware annotation area */ - fas = dpaa2_get_fas(sgt_buf); + fas = dpaa2_get_fas(sgt_buf, true); memset(fas, 0, DPAA2_FAS_SIZE); sgt = (struct dpaa2_sg_entry *)(sgt_buf + priv->tx_data_offset); @@ -458,7 +458,7 @@ static int build_single_fd(struct dpaa2_ * on TX confirmation. We are clearing FAS (Frame Annotation Status) * field from the hardware annotation area */ - fas = dpaa2_get_fas(buffer_start); + fas = dpaa2_get_fas(buffer_start, true); memset(fas, 0, DPAA2_FAS_SIZE); /* Store a backpointer to the skb at the beginning of the buffer @@ -510,7 +510,7 @@ static void free_tx_fd(const struct dpaa fd_addr = dpaa2_fd_get_addr(fd); skbh = dpaa2_iova_to_virt(priv->iommu_domain, fd_addr); - fas = dpaa2_get_fas(skbh); + fas = dpaa2_get_fas(skbh, true); if (fd_format == dpaa2_fd_single) { skb = *skbh; --- a/drivers/staging/fsl-dpaa2/ethernet/dpaa2-eth.h +++ b/drivers/staging/fsl-dpaa2/ethernet/dpaa2-eth.h @@ -153,10 +153,15 @@ struct dpaa2_fas { #define DPAA2_FAS_SIZE (sizeof(struct dpaa2_fas)) /* Accessors for the hardware annotation fields that we use */ -#define dpaa2_get_hwa(buf_addr) \ - ((void *)(buf_addr) + DPAA2_ETH_SWA_SIZE) -#define dpaa2_get_fas(buf_addr) \ - (struct dpaa2_fas *)(dpaa2_get_hwa(buf_addr) + DPAA2_FAS_OFFSET) +static inline void *dpaa2_get_hwa(void *buf_addr, bool swa) +{ + return buf_addr + (swa ? DPAA2_ETH_SWA_SIZE : 0); +} + +static inline struct dpaa2_fas *dpaa2_get_fas(void *buf_addr, bool swa) +{ + return dpaa2_get_hwa(buf_addr, swa) + DPAA2_FAS_OFFSET; +} /* Error and status bits in the frame annotation status word */ /* Debug frame, otherwise supposed to be discarded */ Patches currently in stable-queue which might be from ruxandra.radulescu(a)nxp.com are queue-4.15/staging-fsl-dpaa2-eth-fix-access-to-fas-field.patch

7 years, 4 months

1
0
0 0

Patch "spi: sun6i: disable/unprepare clocks on remove" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled spi: sun6i: disable/unprepare clocks on remove to the 4.15-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: spi-sun6i-disable-unprepare-clocks-on-remove.patch and it can be found in the queue-4.15 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 Fri Mar 16 15:11:08 CET 2018 From: Tobias Jordan <Tobias.Jordan(a)elektrobit.com> Date: Thu, 7 Dec 2017 15:04:53 +0100 Subject: spi: sun6i: disable/unprepare clocks on remove From: Tobias Jordan <Tobias.Jordan(a)elektrobit.com> [ Upstream commit 2d9bbd02c54094ceffa555143b0d68cd06504d63 ] sun6i_spi_probe() uses sun6i_spi_runtime_resume() to prepare/enable clocks, so sun6i_spi_remove() should use sun6i_spi_runtime_suspend() to disable/unprepare them if we're not suspended. Replacing pm_runtime_disable() by pm_runtime_force_suspend() will ensure that sun6i_spi_runtime_suspend() is called if needed. Found by Linux Driver Verification project (linuxtesting.org). Fixes: 3558fe900e8af (spi: sunxi: Add Allwinner A31 SPI controller driver) Signed-off-by: Tobias Jordan <Tobias.Jordan(a)elektrobit.com> Acked-by: Maxime Ripard <maxime.ripard(a)free-electrons.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> --- drivers/spi/spi-sun6i.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/spi/spi-sun6i.c +++ b/drivers/spi/spi-sun6i.c @@ -541,7 +541,7 @@ err_free_master: static int sun6i_spi_remove(struct platform_device *pdev) { - pm_runtime_disable(&pdev->dev); + pm_runtime_force_suspend(&pdev->dev); return 0; } Patches currently in stable-queue which might be from Tobias.Jordan(a)elektrobit.com are queue-4.15/spi-sun6i-disable-unprepare-clocks-on-remove.patch

7 years, 4 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror