1. 30 11月, 2019 1 次提交
    • H
      s390/zcrypt: handle new reply code FILTERED_BY_HYPERVISOR · 6733775a
      Harald Freudenberger 提交于
      This patch introduces support for a new architectured reply
      code 0x8B indicating that a hypervisor layer (if any) has
      rejected an ap message.
      
      Linux may run as a guest on top of a hypervisor like zVM
      or KVM. So the crypto hardware seen by the ap bus may be
      restricted by the hypervisor for example only a subset like
      only clear key crypto requests may be supported. Other
      requests will be filtered out - rejected by the hypervisor.
      The new reply code 0x8B will appear in such cases and needs
      to get recognized by the ap bus and zcrypt device driver zoo.
      Signed-off-by: NHarald Freudenberger <freude@linux.ibm.com>
      Signed-off-by: NVasily Gorbik <gor@linux.ibm.com>
      6733775a
  2. 23 11月, 2019 2 次提交
  3. 22 11月, 2019 9 次提交
    • P
      can: m_can_platform: remove unnecessary m_can_class_resume() call · 0704c574
      Pankaj Sharma 提交于
      The function m_can_runtime_resume() is getting recursively called from
      m_can_class_resume(). This results in a lock up.
      
      We need not call m_can_class_resume() during m_can_runtime_resume().
      
      Fixes: f524f829 ("can: m_can: Create a m_can platform framework")
      Signed-off-by: NPankaj Sharma <pankj.sharma@samsung.com>
      Signed-off-by: NSriram Dash <sriram.dash@samsung.com>
      Acked-by: NDan Murphy <dmurphy@ti.com>
      Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>
      0704c574
    • P
      can: m_can_platform: set net_device structure as driver data · 2ea87249
      Pankaj Sharma 提交于
      The current code is failing during clock prepare enable because of not
      getting proper clock from platform device.
      
      [    0.852089] Call trace:
      [    0.854516]  0xffff0000fa22a668
      [    0.857638]  clk_prepare+0x20/0x34
      [    0.861019]  m_can_runtime_resume+0x2c/0xe4
      [    0.865180]  pm_generic_runtime_resume+0x28/0x38
      [    0.869770]  __rpm_callback+0x16c/0x1bc
      [    0.873583]  rpm_callback+0x24/0x78
      [    0.877050]  rpm_resume+0x428/0x560
      [    0.880517]  __pm_runtime_resume+0x7c/0xa8
      [    0.884593]  m_can_clk_start.isra.9.part.10+0x1c/0xa8
      [    0.889618]  m_can_class_register+0x138/0x370
      [    0.893950]  m_can_plat_probe+0x120/0x170
      [    0.897939]  platform_drv_probe+0x4c/0xa0
      [    0.901924]  really_probe+0xd8/0x31c
      [    0.905477]  driver_probe_device+0x58/0xe8
      [    0.909551]  device_driver_attach+0x68/0x70
      [    0.913711]  __driver_attach+0x9c/0xf8
      [    0.917437]  bus_for_each_dev+0x50/0xa0
      [    0.921251]  driver_attach+0x20/0x28
      [    0.924804]  bus_add_driver+0x148/0x1fc
      [    0.928617]  driver_register+0x6c/0x124
      [    0.932431]  __platform_driver_register+0x48/0x50
      [    0.937113]  m_can_plat_driver_init+0x18/0x20
      [    0.941446]  do_one_initcall+0x4c/0x19c
      [    0.945259]  kernel_init_freeable+0x1d0/0x280
      [    0.949591]  kernel_init+0x10/0x100
      [    0.953057]  ret_from_fork+0x10/0x18
      [    0.956614] Code: 00000000 00000000 00000000 00000000 (fa22a668)
      [    0.962681] ---[ end trace 881f71bd609de763 ]---
      [    0.967301] Kernel panic - not syncing: Attempted to kill init!
      
      A device driver for CAN controller hardware registers itself with the
      Linux network layer as a network device. So, the driver data for m_can
      should ideally be of type net_device.
      
      Fixes: f524f829 ("can: m_can: Create a m_can platform framework")
      Signed-off-by: NPankaj Sharma <pankj.sharma@samsung.com>
      Signed-off-by: NSriram Dash <sriram.dash@samsung.com>
      Acked-by: NDan Murphy <dmurphy@ti.com>
      Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>
      2ea87249
    • H
      hv_netvsc: Fix send_table offset in case of a host bug · 171c1fd9
      Haiyang Zhang 提交于
      If negotiated NVSP version <= NVSP_PROTOCOL_VERSION_6, the offset may
      be wrong (too small) due to a host bug. This can cause missing the
      end of the send indirection table, and add multiple zero entries from
      leading zeros before the data region. This bug adds extra burden on
      channel 0.
      
      So fix the offset by computing it from the data structure sizes. This
      will ensure netvsc driver runs normally on unfixed hosts, and future
      fixed hosts.
      
      Fixes: 5b54dac8 ("hyperv: Add support for virtual Receive Side Scaling (vRSS)")
      Signed-off-by: NHaiyang Zhang <haiyangz@microsoft.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      171c1fd9
    • H
      hv_netvsc: Fix offset usage in netvsc_send_table() · 71f21959
      Haiyang Zhang 提交于
      To reach the data region, the existing code adds offset in struct
      nvsp_5_send_indirect_table on the beginning of this struct. But the
      offset should be based on the beginning of its container,
      struct nvsp_message. This bug causes the first table entry missing,
      and adds an extra zero from the zero pad after the data region.
      This can put extra burden on the channel 0.
      
      So, correct the offset usage. Also add a boundary check to ensure
      not reading beyond data region.
      
      Fixes: 5b54dac8 ("hyperv: Add support for virtual Receive Side Scaling (vRSS)")
      Signed-off-by: NHaiyang Zhang <haiyangz@microsoft.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      71f21959
    • M
      sfc: Only cancel the PPS workqueue if it exists · 723eb536
      Martin Habets 提交于
      The workqueue only exists for the primary PF. For other functions
      we hit a WARN_ON in kernel/workqueue.c.
      
      Fixes: 7c236c43 ("sfc: Add support for IEEE-1588 PTP")
      Signed-off-by: NMartin Habets <mhabets@solarflare.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      723eb536
    • O
      nfc: port100: handle command failure cleanly · 5f9f0b11
      Oliver Neukum 提交于
      If starting the transfer of a command suceeds but the transfer for the reply
      fails, it is not enough to initiate killing the transfer for the
      command may still be running. You need to wait for the killing to finish
      before you can reuse URB and buffer.
      
      Reported-and-tested-by: syzbot+711468aa5c3a1eabf863@syzkaller.appspotmail.com
      Signed-off-by: NOliver Neukum <oneukum@suse.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5f9f0b11
    • N
      nbd: prevent memory leak · 03bf73c3
      Navid Emamdoost 提交于
      In nbd_add_socket when krealloc succeeds, if nsock's allocation fail the
      reallocted memory is leak. The correct behaviour should be assigning the
      reallocted memory to config->socks right after success.
      Reviewed-by: NJosef Bacik <josef@toxicpanda.com>
      Signed-off-by: NNavid Emamdoost <navid.emamdoost@gmail.com>
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      03bf73c3
    • A
      nvme: hwmon: add quirk to avoid changing temperature threshold · 6c6aa2f2
      Akinobu Mita 提交于
      This adds a new quirk NVME_QUIRK_NO_TEMP_THRESH_CHANGE to avoid changing
      the value of the temperature threshold feature for specific devices that
      show undesirable behavior.
      
      Guenter reported:
      
      "On my Intel NVME drive (SSDPEKKW512G7), writing any minimum limit on the
      Composite temperature sensor results in a temperature warning, and that
      warning is sticky until I reset the controller.
      
      It doesn't seem to matter which temperature I write; writing -273000 has
      the same result."
      
      The Intel NVMe has the latest firmware version installed, so this isn't
      a problem that was ever fixed.
      Reported-by: NGuenter Roeck <linux@roeck-us.net>
      Cc: Keith Busch <kbusch@kernel.org>
      Cc: Jens Axboe <axboe@fb.com>
      Cc: Christoph Hellwig <hch@lst.de>
      Cc: Sagi Grimberg <sagi@grimberg.me>
      Cc: Jean Delvare <jdelvare@suse.com>
      Reviewed-by: NGuenter Roeck <linux@roeck-us.net>
      Tested-by: NGuenter Roeck <linux@roeck-us.net>
      Signed-off-by: NAkinobu Mita <akinobu.mita@gmail.com>
      Signed-off-by: NKeith Busch <kbusch@kernel.org>
      6c6aa2f2
    • A
      nvme: hwmon: provide temperature min and max values for each sensor · 52deba0f
      Akinobu Mita 提交于
      According to the NVMe specification, the over temperature threshold and
      under temperature threshold features shall be implemented for Composite
      Temperature if a non-zero WCTEMP field value is reported in the Identify
      Controller data structure.  The features are also implemented for all
      implemented temperature sensors (i.e., all Temperature Sensor fields that
      report a non-zero value).
      
      This provides the over temperature threshold and under temperature
      threshold for each sensor as temperature min and max values of hwmon
      sysfs attributes.
      
      The WCTEMP is already provided as a temperature max value for Composite
      Temperature, but this change isn't incompatible.  Because the default
      value of the over temperature threshold for Composite Temperature is
      the WCTEMP.
      
      Now the alarm attribute for Composite Temperature indicates one of the
      temperature is outside of a temperature threshold.  Because there is only
      a single bit in Critical Warning field that indicates a temperature is
      outside of a threshold.
      
      Example output from the "sensors" command:
      
      nvme-pci-0100
      Adapter: PCI adapter
      Composite:    +33.9°C  (low  = -273.1°C, high = +69.8°C)
                             (crit = +79.8°C)
      Sensor 1:     +34.9°C  (low  = -273.1°C, high = +65261.8°C)
      Sensor 2:     +31.9°C  (low  = -273.1°C, high = +65261.8°C)
      Sensor 5:     +47.9°C  (low  = -273.1°C, high = +65261.8°C)
      
      This also adds helper macros for kelvin from/to milli Celsius conversion,
      and replaces the repeated code in hwmon.c.
      
      Cc: Keith Busch <kbusch@kernel.org>
      Cc: Jens Axboe <axboe@fb.com>
      Cc: Christoph Hellwig <hch@lst.de>
      Cc: Sagi Grimberg <sagi@grimberg.me>
      Cc: Jean Delvare <jdelvare@suse.com>
      Reviewed-by: NGuenter Roeck <linux@roeck-us.net>
      Tested-by: NGuenter Roeck <linux@roeck-us.net>
      Signed-off-by: NAkinobu Mita <akinobu.mita@gmail.com>
      Signed-off-by: NKeith Busch <kbusch@kernel.org>
      52deba0f
  4. 21 11月, 2019 27 次提交
  5. 20 11月, 2019 1 次提交
反馈
建议
客服 返回
顶部