- Apr 12, 2019
-
-
Weiyi Lu authored
CLK_SET_RATE_PARENT would be dropped. Merge two flag setting together to correct the error. Fixes: 5a1cc4c2 ("clk: mediatek: Add flags to mtk_gate") Cc: <stable@vger.kernel.org> Signed-off-by:
Weiyi Lu <weiyi.lu@mediatek.com> Reviewed-by:
Matthias Brugger <matthias.bgg@gmail.com> Signed-off-by:
Stephen Boyd <sboyd@kernel.org>
-
- Apr 11, 2019
-
-
Stephen Boyd authored
It's used by probe and that isn't an init function. Drop this so that we don't get a section mismatch. Reported-by:
kbuild test robot <lkp@intel.com> Cc: David Müller <dave.mueller@gmx.ch> Cc: Hans de Goede <hdegoede@redhat.com> Cc: Andy Shevchenko <andy.shevchenko@gmail.com> Fixes: 7c2e0713 ("clk: x86: Add system specific quirk to mark clocks as critical") Signed-off-by:
Stephen Boyd <sboyd@kernel.org>
-
- Apr 10, 2019
-
-
David Müller authored
Since commit 648e9218 ("clk: x86: Stop marking clocks as CLK_IS_CRITICAL"), the pmc_plt_clocks of the Bay Trail SoC are unconditionally gated off. Unfortunately this will break systems where these clocks are used for external purposes beyond the kernel's knowledge. Fix it by implementing a system specific quirk to mark the necessary pmc_plt_clks as critical. Fixes: 648e9218 ("clk: x86: Stop marking clocks as CLK_IS_CRITICAL") Signed-off-by:
David Müller <dave.mueller@gmx.ch> Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Reviewed-by:
Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by:
Stephen Boyd <sboyd@kernel.org>
-
- Mar 29, 2019
-
-
Neil Armstrong authored
The vid_pll_div is a programmable fractional divider, but vendor gives a limited of known configuration value and it's corresponding fraction. Thus when at reset value (0) or unknown value, we cannot determine the result rate. The initial behaviour was to print a warning, but the warning triggers at each boot and when the clock tree is refreshed. This patch moves the print to debug and returns 0 instead of the parent rate. Fixes: 72dbb8c9 ("clk: meson: Add vid_pll divider driver") Signed-off-by:
Neil Armstrong <narmstrong@baylibre.com> Reviewed-by:
Jerome Brunet <jbrunet@baylibre.com> Link: https://lkml.kernel.org/r/20190327151348.27402-1-narmstrong@baylibre.com
-
- Mar 25, 2019
-
-
Martin Blumenstingl authored
Make meson_clk_pll_is_better() consider a rate that precisely matches the requested rate to be better than any previous rate (which was smaller than the current). Prior to commit 8eed1db1 ("clk: meson: pll: update driver for the g12a") meson_clk_get_pll_settings() returned early (before calling meson_clk_pll_is_better()) if the rate from the current iteration matches the requested rate precisely. After this commit meson_clk_pll_is_better() is called unconditionally. This requires meson_clk_pll_is_better() to work with the case where "now == rate". This fixes a hang during boot on Meson8b / Odroid-C1 for me. Fixes: 8eed1db1 ("clk: meson: pll: update driver for the g12a") Signed-off-by:
Martin Blumenstingl <martin.blumenstingl@googlemail.com> Reviewed-by:
Jerome Brunet <jbrunet@baylibre.com> Signed-off-by:
Neil Armstrong <narmstrong@baylibre.com> Link: https://lkml.kernel.org/r/20190324164327.22590-2-martin.blumenstingl@googlemail.com
-
- Mar 19, 2019
-
-
Neil Armstrong authored
First two VPU clock parents are wrong, fix it here. Fixes: 085a4ea9 ("clk: meson: g12a: add peripheral clock controller") Signed-off-by:
Neil Armstrong <narmstrong@baylibre.com> Acked-by:
Jerome Brunet <jbrunet@baylibre.com> Link: https://lkml.kernel.org/r/20190313135503.3198-1-narmstrong@baylibre.com
-
Maxime Jourdan authored
There are 8 parents, use 0x7 Fixes: 085a4ea9 ("clk: meson: g12a: add peripheral clock controller") Signed-off-by:
Maxime Jourdan <mjourdan@baylibre.com> Acked-by:
Neil Armstrong <narmstrong@baylibre.com> Signed-off-by:
Neil Armstrong <narmstrong@baylibre.com> Link: https://lkml.kernel.org/r/20190319082611.6215-1-mjourdan@baylibre.com
-
Maxime Jourdan authored
We want the video decoder clocks to always round to closest. While the muxes are already using CLK_MUX_ROUND_CLOSEST, the corresponding CLK_DIVIDER_ROUND_CLOSEST was forgotten for the dividers. Fix this by adding the flag to the two vdec dividers. Fixes: a565242e ("clk: meson: gxbb: add the video decoder clocks") Signed-off-by:
Maxime Jourdan <mjourdan@baylibre.com> Acked-by:
Neil Armstrong <narmstrong@baylibre.com> Signed-off-by:
Neil Armstrong <narmstrong@baylibre.com> Link: https://lkml.kernel.org/r/20190319102537.2043-1-mjourdan@baylibre.com
-
- Mar 18, 2019
-
-
Matthias Wieloch authored
The prescaler formula of the programmable clock has changed for sama5d2. Update the driver accordingly. Fixes: a2038077 ("clk: at91: add sama5d2 PMC driver") Cc: <stable@vger.kernel.org> # v4.20+ Signed-off-by:
Nicolas Ferre <nicolas.ferre@microchip.com> [nicolas.ferre@microchip.com: adapt the prescaler range, fix clk_programmable_recalc_rate, split patch] Signed-off-by:
Matthias Wieloch <matthias.wieloch@few-bauer.de> Signed-off-by:
Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by:
Stephen Boyd <sboyd@kernel.org>
-
- Mar 15, 2019
-
-
Aaron Ma authored
Add a non-NULL check to fix potential NULL pointer dereference Cleanup code to call function once. Signed-off-by:
Aaron Ma <aaron.ma@canonical.com> Fixes: 2bf9a0a1 ('iommu/amd: Add iommu support for ACPI HID devices') Signed-off-by:
Joerg Roedel <jroedel@suse.de>
-
David Hildenbrand authored
The XEN balloon driver - in contrast to other balloon drivers - allows to map some inflated pages to user space. Such pages are allocated via alloc_xenballooned_pages() and freed via free_xenballooned_pages(). The pfn space of these allocated pages is used to map other things by the hypervisor using hypercalls. Pages marked with PG_offline must never be mapped to user space (as this page type uses the mapcount field of struct pages). So what we can do is, clear/set PG_offline when allocating/freeing an inflated pages. This way, most inflated pages can be excluded by dumping tools and the "reused for other purpose" balloon pages are correctly not marked as PG_offline. Fixes: 77c4adf6 (xen/balloon: mark inflated pages PG_offline) Reported-by:
Julien Grall <julien.grall@arm.com> Tested-by:
Julien Grall <julien.grall@arm.com> Signed-off-by:
David Hildenbrand <david@redhat.com> Reviewed-by:
Juergen Gross <jgross@suse.com> Signed-off-by:
Juergen Gross <jgross@suse.com>
-
- Mar 14, 2019
-
-
Dave Rodgman authored
lzo-rle gives higher performance and similar compression ratios to lzo. Link: http://lkml.kernel.org/r/20190205155944.16007-4-dave.rodgman@arm.com Signed-off-by:
Dave Rodgman <dave.rodgman@arm.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Sagar Biradar authored
Fix performance issue where the queue depth for SmartIOC logical volumes is set to 1, and allow the usual logical volume code to be executed Fixes: a052865f (aacraid: Set correct Queue Depth for HBA1000 RAW disks) Cc: stable@vger.kernel.org Signed-off-by:
Sagar Biradar <Sagar.Biradar@microchip.com> Reviewed-by:
Dave Carroll <david.carroll@microsemi.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com>
-
Dan Carpenter authored
It used to be that "error" was set to -ENODEV at the start of the function but we shifted some code around an now "error" is set to zero for most error paths. There is a mix of direct returns and "goto out" but I changed everything to direct returns for consistency. Fixes: 56de8357 ("scsi: lpfc: fix calls to dma_set_mask_and_coherent()") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Acked-by:
James Smart <james.smart@broadcom.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com>
-
- Mar 13, 2019
-
-
Xin Long authored
sk_setup_caps() is called to set sk->sk_dst_cache in pptp_connect, so we have to dst_release(sk->sk_dst_cache) in pptp_sock_destruct, otherwise, the dst refcnt will leak. It can be reproduced by this syz log: r1 = socket$pptp(0x18, 0x1, 0x2) bind$pptp(r1, &(0x7f0000000100)={0x18, 0x2, {0x0, @local}}, 0x1e) connect$pptp(r1, &(0x7f0000000000)={0x18, 0x2, {0x3, @remote}}, 0x1e) Consecutive dmesg warnings will occur: unregister_netdevice: waiting for lo to become free. Usage count = 1 v1->v2: - use rcu_dereference_protected() instead of rcu_dereference_check(), as suggested by Eric. Fixes: 00959ade ("PPTP: PPP over IPv4 (Point-to-Point Tunneling Protocol)") Reported-by:
Xiumei Mu <xmu@redhat.com> Signed-off-by:
Xin Long <lucien.xin@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Bryan Whitehead authored
It has been observed that tx queue may stall while downloading from certain web sites (example www.speedtest.net) The cause has been tracked down to a corner case where the tx interrupt vector was disabled automatically, but was not re enabled later. The lan743x has two mechanisms to enable/disable individual interrupts. Interrupts can be enabled/disabled by individual source, and they can also be enabled/disabled by individual vector which has been mapped to the source. Both must be enabled for interrupts to work properly. The TX code path, primarily uses the interrupt enable/disable of the TX source bit, while leaving the vector enabled all the time. However, while investigating this issue it was noticed that the driver requested the use of the vector auto clear feature. The test above revealed a case where the vector enable was cleared unintentionally. This patch fixes the issue by deleting the lines that request the vector auto clear feature to be used. Fixes: 23f0703c ("lan743x: Add main source files for new lan743x driver") Signed-off-by:
Bryan Whitehead <Bryan.Whitehead@microchip.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Sagi Grimberg authored
A C2HData PDU with the SUCCESS flag set indicates that the I/O was completed by the controller successfully and means that a subsequent completion response capsule PDU will be ommitted. If we see this flag, fisrt we check that LAST_PDU flag is set as well, and then we complete the request when the data transfer (and data digest verification if its on) is done. While we're at it, reuse a bit of code with nvme_fail_request. Reported-by:
Steve Blightman <steve.blightman@oracle.com> Suggested-by:
Oliver Smith-Denny <osmithde@cisco.com> Signed-off-by:
Sagi Grimberg <sagi@grimberg.me> Reviewed-by:
Oliver Smith-Denny <osmithde@cisco.com> Tested-by:
Oliver Smith-Denny <osmithde@cisco.com> Signed-off-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
Jens Axboe <axboe@kernel.dk>
-
Christoph Hellwig authored
NVMe DSM is a pure hint, so if the underlying device / file system does not support discard-like operations we should not fail the operation but rather return success. Fixes: 3b031d15 ("nvmet: add error log support for bdev backend") Signed-off-by:
Christoph Hellwig <hch@lst.de> Reviewed by: Chaitanya Kulkarni <chaitanya.kulkarni@wdc.com> Tested-by:
Sagi Grimberg <sagi@grimberg.me> Signed-off-by:
Jens Axboe <axboe@kernel.dk>
-
Christoph Hellwig authored
Add a gendisk argument to nvme_config_write_zeroes so that the call to nvme_update_disk_info for the multipath device node updates the proper request_queue. Signed-off-by:
Christoph Hellwig <hch@lst.de> Reviewed-by:
Keith Busch <keith.busch@intel.com> Reviewed-by:
Max Gurtovoy <maxg@mellanox.com> Tested-by:
Sagi Grimberg <sagi@grimberg.me> Signed-off-by:
Jens Axboe <axboe@kernel.dk>
-
Christoph Hellwig authored
Add a gendisk argument to nvme_config_discard so that the call to nvme_update_disk_info for the multipath device node updates the proper request_queue. Signed-off-by:
Christoph Hellwig <hch@lst.de> Reported-by:
Sagi Grimberg <sagi@grimberg.me> Reviewed-by:
Keith Busch <keith.busch@intel.com> Reviewed-by:
Max Gurtovoy <maxg@mellanox.com> Tested-by:
Sagi Grimberg <sagi@grimberg.me> Signed-off-by:
Jens Axboe <axboe@kernel.dk>
-
Christoph Hellwig authored
Just opencode the two function calls in the caller. Signed-off-by:
Christoph Hellwig <hch@lst.de> Reviewed-by:
Keith Busch <keith.busch@intel.com> Reviewed-by:
Max Gurtovoy <maxg@mellanox.com> Reviewed-by:
Chaitanya Kulkarni <chaitanya.kulkarni@wdc.com> Tested-by:
Sagi Grimberg <sagi@grimberg.me> Signed-off-by:
Jens Axboe <axboe@kernel.dk>
-
Christoph Hellwig authored
Qemu started out with a broken implementation of Write Zeroes written by yours truly. Disable Write Zeroes on qemu for now, eventually we need to go back and make all the qemu quirks version specific, but that is left for another time. Signed-off-by:
Christoph Hellwig <hch@lst.de> Reviewed-by:
Keith Busch <keith.busch@intel.com> Tested-by:
Ming Lei <ming.lei@redhat.com> Signed-off-by:
Jens Axboe <axboe@kernel.dk>
-
James Smart authored
The FC-NVME spec, when finally approved, modified the disconnect LS such that the only scope available is the association. Rework the Disconnect LS processing to be in accordance with the change. Signed-off-by:
Nigel Kirkland <nigel.kirkland@broadcom.com> Signed-off-by:
James Smart <jsmart2021@gmail.com> Reviewed-by:
Ewan D. Milne <emilne@redhat.com> Signed-off-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
Jens Axboe <axboe@kernel.dk>
-
James Smart authored
There are two changes: 1) The logic in the __nvmet_fc_free_assoc() routine is bad. It uses "safe" routines assuming pointers will come back valid. However, the intervening next structure being linked can be removed from the list and the resulting safe pointers are bad, resulting in NULL ptrs being hit. Correct by scheduling a work element to perform the association delete, which can be done while under lock. 2) Prior patch that added the work element scheduling left a possible reference on the object if the work element couldn't be scheduled. Correct by doing the put on a failing schedule_work() call. Signed-off-by:
Nigel Kirkland <nigel.kirkland@broadcom.com> Signed-off-by:
James Smart <jsmart2021@gmail.com> Reviewed-by:
Ewan D. Milne <emilne@redhat.com> Signed-off-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
Jens Axboe <axboe@kernel.dk>
-
James Smart authored
If: - A successful connect has occurred with an io queue count greater than zero and namespaces detected and running. - An error or something occurs which causes a termination of the prior association and then starts a reconnect, - The reconnect then creates a new controller, but for whatever reason, nvme_set_queue_count() results in io queue count set to zero. This will skip io queue and tag set changes. - But... the controller will transition to live, calling nvme_start_ctrl, which calls nvme_start_queues(), which then releases I/Os into the transport which then sends them to the driver. As there are no queues, things eventually hit the driver looking for a handle, which was cleared when the original controller was reset, and it can't proceed. Worst case, things progress, but everything fails. In the failing scenario, the nvme_set_features(NVME_FEAT_NUM_QUEUES) command actually failed with a NVME_SC_INTERNAL error. For some reason, although nvme_set_queue_count() saw the error and set io queue count to zero, it doesn't return a failure status to the transport, which allows the transport to continue using the controller. Fix the problem by simply rejecting the new association if at least 1 I/O queue can't be created. The association reject will fail the reconnect attempt and fall into the reconnect retry policy. Signed-off-by:
James Smart <jsmart2021@gmail.com> Reviewed-by:
Sagi Grimberg <sagi@grimberg.me> Signed-off-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
Jens Axboe <axboe@kernel.dk>
-
James Smart authored
A recent change added a numa_node field to the nvme controller and has the transport assign the node using dev_to_node(). However, fcloop registers with a NULL device struct, so the dev_to_node() call oops. Revise the assignment to assign no node when device struct is null. Fixes: 103e515e ("nvme: add a numa_node field to struct nvme_ctrl") Reported-by:
Mike Snitzer <snitzer@redhat.com> Signed-off-by:
James Smart <jsmart2021@gmail.com> Reviewed-by:
Sagi Grimberg <sagi@grimberg.me> Reviewed-by:
Hannes Reinecke <hare@suse.com> Reviewed-by:
Mike Snitzer <snitzer@redhat.com> [hch: small coding style fixup] Signed-off-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
Jens Axboe <axboe@kernel.dk>
-
James Smart authored
For some nvme command, when issued by the nvme core layer, there is an internal buffer which can cause blk_rq_payload_bytes() to return a non-zero value yet there is no actual/real command payload and sg list. An example is the WRITE ZEROES command. To address this, when making choices on whether to dma map an sgl, use blk_rq_nr_phys_segments() instead of blk_rq_payload_bytes(). When there is a sgl, blk_rq_payload_bytes() will return the amount of data to be transferred by the sgl. Signed-off-by:
Chaitanya Kulkarni <chaitanya.kulkarni@wdc.com> Signed-off-by:
James Smart <jsmart2021@gmail.com> Signed-off-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
Jens Axboe <axboe@kernel.dk>
-
Yufen Yu authored
After commit 4d43d395 (workqueue: Try to catch flush_work() without INIT_WORK()), it can cause warning when delete nvme-loop device, trace like: [ 76.601272] Call Trace: [ 76.601646] ? del_timer+0x72/0xa0 [ 76.602156] __cancel_work_timer+0x1ae/0x270 [ 76.602791] cancel_work_sync+0x14/0x20 [ 76.603407] nvmet_ctrl_free+0x1b7/0x2f0 [nvmet] [ 76.604091] ? free_percpu+0x168/0x300 [ 76.604652] nvmet_sq_destroy+0x106/0x240 [nvmet] [ 76.605346] nvme_loop_destroy_admin_queue+0x30/0x60 [nvme_loop] [ 76.606220] nvme_loop_shutdown_ctrl+0xc3/0xf0 [nvme_loop] [ 76.607026] nvme_loop_delete_ctrl_host+0x19/0x30 [nvme_loop] [ 76.607871] nvme_do_delete_ctrl+0x75/0xb0 [ 76.608477] nvme_sysfs_delete+0x7d/0xc0 [ 76.609057] dev_attr_store+0x24/0x40 [ 76.609603] sysfs_kf_write+0x4c/0x60 [ 76.610144] kernfs_fop_write+0x19a/0x260 [ 76.610742] __vfs_write+0x1c/0x60 [ 76.611246] vfs_write+0xfa/0x280 [ 76.611739] ksys_write+0x6e/0x120 [ 76.612238] __x64_sys_write+0x1e/0x30 [ 76.612787] do_syscall_64+0xbf/0x3a0 [ 76.613329] entry_SYSCALL_64_after_hwframe+0x44/0xa9 We fix it by moving fatal_err_work init to nvmet_alloc_ctrl(), which may more reasonable. Signed-off-by:
Yufen Yu <yuyufen@huawei.com> Reviewed-by:
Sagi Grimberg <sagi@grimberg.me> Reviewed-by:
Bart Van Assche <bvanassche@acm.org> Signed-off-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
Jens Axboe <axboe@kernel.dk>
-
Yufen Yu authored
After commit a686ed75 ("nvme: introduce a helper function for controller deletion), nvme_delete_ctrl_sync no longer use flush_work. Update comment, accordingly. Signed-off-by:
Yufen Yu <yuyufen@huawei.com> Signed-off-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
Jens Axboe <axboe@kernel.dk>
-
Sagi Grimberg authored
In case nvme_alloc_ns fails after we initialize ns_head but before we add the ns to the controller namespaces list we need to explicitly put the ns_head reference because when we teardown the controller we won't find it, causing us to leak a dangling subsystem eventually. Signed-off-by:
Sagi Grimberg <sagi@grimberg.me> Signed-off-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
Jens Axboe <axboe@kernel.dk>
-
Keith Busch authored
The field is defined to be a 24 byte array, we don't need to multiply the sizeof() that field by the number of dwords it covers. Signed-off-by:
Keith Busch <keith.busch@intel.com> Reviewed-by:
Sagi Grimberg <sagi@grimberg.me> Signed-off-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
Jens Axboe <axboe@kernel.dk>
-
Keith Busch authored
A write or flush IO passthrough command is expected to change the logical block content, so don't warn on these as no additional handling is necessary. Signed-off-by:
Keith Busch <keith.busch@intel.com> Reviewed-by:
Sagi Grimberg <sagi@grimberg.me> Signed-off-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
Jens Axboe <axboe@kernel.dk>
-
Max Gurtovoy authored
This will print get-feature cmd in more informative way. For example, run "nvme get-feature /dev/nvme0 -n 1 -f 0x9 -c 10" will trace: nvme-3907 [008] .... 1763.635054: nvme_setup_cmd: nvme0: qid=0, cmdid=6, nsid=1, flags=0x0, meta=0x0, cmd=(nvme_admin_get_features fid=0x9 sel=0x0 cdw11=0xa) <idle>-0 [001] d.h. 1763.635112: nvme_sq: nvme0: qid=0, head=27, tail=27 <idle>-0 [008] ..s. 1763.635121: nvme_complete_rq: nvme0: qid=0, cmdid=6, res=10, retries=0, flags=0x2, status=0 Signed-off-by:
Max Gurtovoy <maxg@mellanox.com> Reviewed-by:
Sagi Grimberg <sagi@grimberg.me> Reviewed-by:
Johannes Thumshirn <jthumshirn@suse.de> Signed-off-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
Jens Axboe <axboe@kernel.dk>
-
Hans de Goede authored
Before this commit the i2c-designware-platdrv assumes that if the pdev has an apci-companion it should use a dynamic adapter-nr and it sets adapter->nr to -1, otherwise it will use pdev->id as adapter->nr. There are 3 ways how platform_device-s to which i2c-designware-platdrv will bind can be instantiated: 1) Through of / devicetree 2) Through ACPI enumeration 3) Explicitly instantiated through platform_device_create + add 1) In case of devicetree-instantiation the drivers/of code always sets pdev->id to PLATFORM_DEVID_NONE, which is -1 so in this case both paths to set adapter->nr end up doing the same thing. 2) In case of ACPI instantiation the device will always have an ACPI-companion, so we are already using dynamic adapter-nrs. 3) There are 2 places manually instantiating a designware_i2c platform_dev: drivers/mfd/intel_quark_i2c_gpio.c drivers/mfd/intel-lpss.c In the intel_quark_i2c_gpio.c case pdev->id is always 0, so switching to dynamic adapter-nrs here could lead to the bus-number no longer being stable, but the quark X1000 only has 1 i2c-controller, which will also be assigned bus-number 0 when using dynamic adapter-nrs. In the intel-lpss.c case intel_lpss_probe() is called from either intel-lpss-acpi.c in which case there always is an ACPI-companion, or from intel-lpss-pci.c. In most cases devices handled by intel-lpss-pci.c also have an ACPI-companion, so we use a dynamic adapter-nr. But in some cases the ACPI-companion is missing and we would use pdev->id (allocated from intel_lpss_devid_ida). Devices which use the intel-lpss-pci.c code typically have many i2c busses, so using pdev->id in this case may lead to a bus-number conflict, triggering a WARN(id < 0, "couldn't get idr") in i2c-core-base.c causing an oops an the adapter registration to fail. So in this case using non dynamic adapter-nrs is actually undesirable. One machine on which this oops was triggering is the Apollo Lake based Acer TravelMate Spin B118. TL;DR: Switching to always using dynamic adapter-numbers does not make any difference in most cases and in the one case where it does make a difference the behavior change is desirable because the old behavior caused an oops. BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1687065 Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Acked-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by:
Jarkko Nikula <jarkko.nikula@linux.intel.com> Signed-off-by:
Wolfram Sang <wsa@the-dreams.de>
-
Hans de Goede authored
i2c-designware-platdrv assumes that if the pdev has an apci-companion it should use a dynamic adapter-nr and otherwise it will use pdev->id as adapter-nr. Before this commit the setting of the adapter.nr was somewhat convoluted, in the acpi_companion case it was set from dw_i2c_acpi_configure, in the non acpi_companion case it was set from dw_i2c_set_fifo_size based on tx_fifo_depth not being set yet indicating that dw_i2c_acpi_configure was not executed. This cleans this up, directly setting the adapter-nr from dw_i2c_plat_probe for both cases. Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Reviewed-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by:
Jarkko Nikula <jarkko.nikula@linux.intel.com> Signed-off-by:
Wolfram Sang <wsa@the-dreams.de>
-
Wolfram Sang authored
Make sure we report 'no buffer' for 0-length messages. This can only happen if threshold is set to 0 which is kind of bogus but we should still handle this situation. Update the docs and add a debug message to educate callers of this function. Reported-by:
Hsin-Yi Wang <hsinyi@chromium.org> Fixes: e94bc5d1 ("i2c: add helpers to ease DMA handling") Signed-off-by:
Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by:
Hsin-Yi Wang <hsinyi@chromium.org> Signed-off-by:
Wolfram Sang <wsa@the-dreams.de>
-
Stephen Rothwell authored
The commit 82c5de0a ("dma-mapping: remove the DMA_MEMORY_EXCLUSIVE flag") removed the "flags" parameter for dma_declare_coherent_memory(). Remove the parameter from the call in rproc_add_virtio_dev(). Signed-off-by:
Stephen Rothwell <sfr@canb.auug.org.au> [bjorn: Extended commit message] Signed-off-by:
Bjorn Andersson <bjorn.andersson@linaro.org>
-
- Mar 12, 2019
-
-
Rafael J. Wysocki authored
After commit 61cb5758 ("cpuidle: Add cpuidle.governor= command line parameter") new cpuidle governors are not added to the list of available governors, so governor selection via sysfs doesn't work as expected (even though it is rarely used anyway). Fix that by making cpuidle_register_governor() add new governors to cpuidle_governors again. Fixes: 61cb5758 ("cpuidle: Add cpuidle.governor= command line parameter") Reported-by:
Kees Cook <keescook@chromium.org> Cc: 5.0+ <stable@vger.kernel.org> # 5.0+ Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-
Jack Morgenstein authored
Calculation of qp mtt size (in function mlx4_RST2INIT_wrapper) ultimately depends on function roundup_pow_of_two. If the amount of memory required by the QP is less than one page, roundup_pow_of_two is called with argument zero. In this case, the roundup_pow_of_two result is undefined. Calling roundup_pow_of_two with a zero argument resulted in the following stack trace: UBSAN: Undefined behaviour in ./include/linux/log2.h:61:13 shift exponent 64 is too large for 64-bit type 'long unsigned int' CPU: 4 PID: 26939 Comm: rping Tainted: G OE 4.19.0-rc1 Hardware name: Supermicro X9DR3-F/X9DR3-F, BIOS 3.2a 07/09/2015 Call Trace: dump_stack+0x9a/0xeb ubsan_epilogue+0x9/0x7c __ubsan_handle_shift_out_of_bounds+0x254/0x29d ? __ubsan_handle_load_invalid_value+0x180/0x180 ? debug_show_all_locks+0x310/0x310 ? sched_clock+0x5/0x10 ? sched_clock+0x5/0x10 ? sched_clock_cpu+0x18/0x260 ? find_held_lock+0x35/0x1e0 ? mlx4_RST2INIT_QP_wrapper+0xfb1/0x1440 [mlx4_core] mlx4_RST2INIT_QP_wrapper+0xfb1/0x1440 [mlx4_core] Fix this by explicitly testing for zero, and returning one if the argument is zero (assuming that the next higher power of 2 in this case should be one). Fixes: c82e9aa0 ("mlx4_core: resource tracking for HCA resources used by guests") Signed-off-by:
Jack Morgenstein <jackm@dev.mellanox.co.il> Signed-off-by:
Tariq Toukan <tariqt@mellanox.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Jack Morgenstein authored
In procedures mlx4_cmd_use_events() and mlx4_cmd_use_polling(), we need to guarantee that there are no FW commands in progress on the comm channel (for VFs) or wrapped FW commands (on the PF) when SRIOV is active. We do this by also taking the slave_cmd_mutex when SRIOV is active. This is especially important when switching from event to polling, since we free the command-context array during the switch. If there are FW commands in progress (e.g., waiting for a completion event), the completion event handler will access freed memory. Since the decision to use comm_wait or comm_poll is taken before grabbing the event_sem/poll_sem in mlx4_comm_cmd_wait/poll, we must take the slave_cmd_mutex as well (to guarantee that the decision to use events or polling and the call to the appropriate cmd function are atomic). Fixes: a7e1f049 ("net/mlx4_core: Fix deadlock when switching between polling and event fw commands") Signed-off-by:
Jack Morgenstein <jackm@dev.mellanox.co.il> Signed-off-by:
Tariq Toukan <tariqt@mellanox.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-