1. 24 7月, 2019 1 次提交
  2. 05 7月, 2019 7 次提交
  3. 03 7月, 2019 23 次提交
  4. 25 6月, 2019 9 次提交
    • G
      staging: erofs: add requirements field in superblock · 64e37023
      Gao Xiang 提交于
      commit 5efe5137f05bbb4688890620934538c005e7d1d6 upstream.
      
      There are some backward incompatible features pending
      for months, mainly due to on-disk format expensions.
      
      However, we should ensure that it cannot be mounted with
      old kernels. Otherwise, it will causes unexpected behaviors.
      
      Fixes: ba2b77a8 ("staging: erofs: add super block operations")
      Cc: <stable@vger.kernel.org> # 4.19+
      Reviewed-by: NChao Yu <yuchao0@huawei.com>
      Signed-off-by: NGao Xiang <gaoxiang25@huawei.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      64e37023
    • T
      drm/vmwgfx: Use the backdoor port if the HB port is not available · e6803ce3
      Thomas Hellstrom 提交于
      commit cc0ba0d8624f210995924bb57a8b181ce8976606 upstream.
      
      The HB port may not be available for various reasons. Either it has been
      disabled by a config option or by the hypervisor for other reasons.
      In that case, make sure we have a backup plan and use the backdoor port
      instead with a performance penalty.
      
      Cc: stable@vger.kernel.org
      Fixes: 89da76fd ("drm/vmwgfx: Add VMWare host messaging capability")
      Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
      Reviewed-by: NDeepak Rawat <drawat@vmware.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e6803ce3
    • J
      can: flexcan: fix timeout when set small bitrate · 4ea81cc4
      Joakim Zhang 提交于
      commit 247e5356a709eb49a0d95ff2a7f07dac05c8252c upstream.
      
      Current we can meet timeout issue when setting a small bitrate like
      10000 as follows on i.MX6UL EVK board (ipg clock = 66MHZ, per clock =
      30MHZ):
      
      | root@imx6ul7d:~# ip link set can0 up type can bitrate 10000
      
      A link change request failed with some changes committed already.
      Interface can0 may have been left with an inconsistent configuration,
      please check.
      
      | RTNETLINK answers: Connection timed out
      
      It is caused by calling of flexcan_chip_unfreeze() timeout.
      
      Originally the code is using usleep_range(10, 20) for unfreeze
      operation, but the patch (8badd65e can: flexcan: avoid calling
      usleep_range from interrupt context) changed it into udelay(10) which is
      only a half delay of before, there're also some other delay changes.
      
      After double to FLEXCAN_TIMEOUT_US to 100 can fix the issue.
      
      Meanwhile, Rasmus Villemoes reported that even with a timeout of 100,
      flexcan_probe() fails on the MPC8309, which requires a value of at least
      140 to work reliably. 250 works for everyone.
      Signed-off-by: NJoakim Zhang <qiangqing.zhang@nxp.com>
      Reviewed-by: NDong Aisheng <aisheng.dong@nxp.com>
      Cc: linux-stable <stable@vger.kernel.org>
      Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4ea81cc4
    • A
      can: xilinx_can: use correct bittiming_const for CAN FD core · f6a2c8b3
      Anssi Hannula 提交于
      commit 904044dd8fff43e289c11a2f90fa532e946a1d8b upstream.
      
      Commit 9e5f1b27 ("can: xilinx_can: add support for Xilinx CAN FD
      core") added a new can_bittiming_const structure for CAN FD cores that
      support larger values for tseg1, tseg2, and sjw than previous Xilinx CAN
      cores, but the commit did not actually take that into use.
      
      Fix that.
      
      Tested with CAN FD core on a ZynqMP board.
      
      Fixes: 9e5f1b27 ("can: xilinx_can: add support for Xilinx CAN FD core")
      Reported-by: NShubhrajyoti Datta <shubhrajyoti.datta@gmail.com>
      Signed-off-by: NAnssi Hannula <anssi.hannula@bitwise.fi>
      Cc: Michal Simek <michal.simek@xilinx.com>
      Reviewed-by: NShubhrajyoti Datta <shubhrajyoti.datta@gmail.com>
      Cc: linux-stable <stable@vger.kernel.org>
      Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f6a2c8b3
    • J
      nvme: Fix u32 overflow in the number of namespace list calculation · 17f1dca2
      Jaesoo Lee 提交于
      [ Upstream commit c8e8c77b3bdbade6e26e8e76595f141ede12b692 ]
      
      The Number of Namespaces (nn) field in the identify controller data structure is
      defined as u32 and the maximum allowed value in NVMe specification is
      0xFFFFFFFEUL. This change fixes the possible overflow of the DIV_ROUND_UP()
      operation used in nvme_scan_ns_list() by casting the nn to u64.
      Signed-off-by: NJaesoo Lee <jalee@purestorage.com>
      Reviewed-by: NChristoph Hellwig <hch@lst.de>
      Signed-off-by: NSagi Grimberg <sagi@grimberg.me>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      17f1dca2
    • R
      hwmon: (pmbus/core) Treat parameters as paged if on multiple pages · d72a4c78
      Robert Hancock 提交于
      [ Upstream commit 4a60570dce658e3f8885bbcf852430b99f65aca5 ]
      
      Some chips have attributes which exist on more than one page but the
      attribute is not presently marked as paged. This causes the attributes
      to be generated with the same label, which makes it impossible for
      userspace to tell them apart.
      
      Marking all such attributes as paged would result in the page suffix
      being added regardless of whether they were present on more than one
      page or not, which might break existing setups. Therefore, we add a
      second check which treats the attribute as paged, even if not marked as
      such, if it is present on multiple pages.
      
      Fixes: b4ce237b ("hwmon: (pmbus) Introduce infrastructure to detect sensors and limit registers")
      Signed-off-by: NRobert Hancock <hancock@sedsystems.ca>
      Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      d72a4c78
    • E
      hwmon: (core) add thermal sensors only if dev->of_node is present · 6029e581
      Eduardo Valentin 提交于
      [ Upstream commit c41dd48e21fae3e55b3670ccf2eb562fc1f6a67d ]
      
      Drivers may register to hwmon and request for also registering
      with the thermal subsystem (HWMON_C_REGISTER_TZ). However,
      some of these driver, e.g. marvell phy, may be probed from
      Device Tree or being dynamically allocated, and in the later
      case, it will not have a dev->of_node entry.
      
      Registering with hwmon without the dev->of_node may result in
      different outcomes depending on the device tree, which may
      be a bit misleading. If the device tree blob has no 'thermal-zones'
      node, the *hwmon_device_register*() family functions are going
      to gracefully succeed, because of-thermal,
      *thermal_zone_of_sensor_register() return -ENODEV in this case,
      and the hwmon error path handles this error code as success to
      cover for the case where CONFIG_THERMAL_OF is not set.
      However, if the device tree blob has the 'thermal-zones'
      entry, the *hwmon_device_register*() will always fail on callers
      with no dev->of_node, propagating -EINVAL.
      
      If dev->of_node is not present, calling of-thermal does not
      make sense. For this reason, this patch checks first if the
      device has a of_node before going over the process of registering
      with the thermal subsystem of-thermal interface. And in this case,
      when a caller of *hwmon_device_register*() with HWMON_C_REGISTER_TZ
      and no dev->of_node will still register with hwmon, but not with
      the thermal subsystem. If all the hwmon part bits are in place,
      the registration will succeed.
      
      Fixes: d560168b ("hwmon: (core) New hwmon registration API")
      Cc: Jean Delvare <jdelvare@suse.com>
      Cc: Guenter Roeck <linux@roeck-us.net>
      Cc: linux-hwmon@vger.kernel.org
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: NEduardo Valentin <eduval@amazon.com>
      Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      6029e581
    • A
      s390/qeth: fix VLAN attribute in bridge_hostnotify udev event · 153f2d97
      Alexandra Winter 提交于
      [ Upstream commit 335726195e460cb6b3f795b695bfd31f0ea70ef0 ]
      
      Enabling sysfs attribute bridge_hostnotify triggers a series of udev events
      for the MAC addresses of all currently connected peers. In case no VLAN is
      set for a peer, the device reports the corresponding MAC addresses with
      VLAN ID 4096. This currently results in attribute VLAN=4096 for all
      non-VLAN interfaces in the initial series of events after host-notify is
      enabled.
      
      Instead, no VLAN attribute should be reported in the udev event for
      non-VLAN interfaces.
      
      Only the initial events face this issue. For dynamic changes that are
      reported later, the device uses a validity flag.
      
      This also changes the code so that it now sets the VLAN attribute for
      MAC addresses with VID 0. On Linux, no qeth interface will ever be
      registered with VID 0: Linux kernel registers VID 0 on all network
      interfaces initially, but qeth will drop .ndo_vlan_rx_add_vid for VID 0.
      Peers with other OSs could register MACs with VID 0.
      
      Fixes: 9f48b9db ("qeth: bridgeport support - address notifications")
      Signed-off-by: NAlexandra Winter <wintera@linux.ibm.com>
      Signed-off-by: NJulian Wiedmann <jwi@linux.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      153f2d97
    • M
      net: ipvlan: Fix ipvlan device tso disabled while NETIF_F_IP_CSUM is set · cedb209b
      Miaohe Lin 提交于
      [ Upstream commit ceae266bf0ae6564ac16d086bf749a096fa90ded ]
      
      There's some NICs, such as hinic, with NETIF_F_IP_CSUM and NETIF_F_TSO
      on but NETIF_F_HW_CSUM off. And ipvlan device features will be
      NETIF_F_TSO on with NETIF_F_IP_CSUM and NETIF_F_IP_CSUM both off as
      IPVLAN_FEATURES only care about NETIF_F_HW_CSUM. So TSO will be
      disabled in netdev_fix_features.
      For example:
      Features for enp129s0f0:
      rx-checksumming: on
      tx-checksumming: on
              tx-checksum-ipv4: on
              tx-checksum-ip-generic: off [fixed]
              tx-checksum-ipv6: on
      
      Fixes: a188222b ("net: Rename NETIF_F_ALL_CSUM to NETIF_F_CSUM_MASK")
      Signed-off-by: NMiaohe Lin <linmiaohe@huawei.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      cedb209b