- 06 4月, 2019 1 次提交
-
-
由 Tony Lindgren 提交于
In preparation of dropping interconnect target module platform data in favor of devicetree based data, we must pass swsup idle quirks to the platform data functions. For now, let's only tag the UART modules with the SWSUP_SIDLE_ACT quirk. The other modules will get tagged with swsup quirks as we drop the platform data and test the changes. Signed-off-by: NTony Lindgren <tony@atomide.com>
-
- 04 4月, 2019 6 次提交
-
-
由 Tony Lindgren 提交于
We cannot access mcpdm registers at all unless there is an optional pdmclk configured. As this is currently only needed for mcpdm, let's check for mcpdm in sysc_get_clocks(). If it turns out to be needed for other modules too, we can add more flags to the quirks table for this. Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Tony Lindgren 提交于
At least mcpdm needs an optional external clock enabled to function and this clock typically comes from the PMIC. We can detect mcpdm based on the interconnect target module address and set a quirk flag early. To do this, let's initialize the clocks a bit later and add a new function for sysc_init_early_quirks(). Note that we cannot yet enable the early quirks for mcpdm until the optional external clocks are handled in the in the following patch. Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Tony Lindgren 提交于
We can do the rsstctrl a bit later, but need to deassert rstctrl reset before the clocks are enabled if asserted. Let's only init restctrl in sysc_init_resets() and do the reset later on just before we enable the device clocks. Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Tony Lindgren 提交于
We are currently not managing interconnect target module clocks in the for legacy platform data based case. This causes a problem for using the platform data based functions when dropping the platform data for the interconnect target module configuration. To avoid a situation where we need to populate the main and optional clocks also for the platform data based functions, let's just manage the clocks directly in ti-sysc driver. This means that until the interconnect target module confugration platform data is dropped our use count for clk_enable() will be 2 instead of 1. Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Tony Lindgren 提交于
The platform data based init functions typically reset the interconnect target module configure the registers. As we may need the interconnect target module specific quirks configured based on the revision register, we want to move the platform data based init to happen later. Let's allocate mdata as needed so it's available for sysc_legacy_init() that we call with module clocks enabled from sysc_init_module(). Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Tony Lindgren 提交于
The first thing we want to do is just read the module revision register to be able to configure the module specific quirks and configure the module registers. As the interconnect target module may not yet be properly configured and may need a reset first, we don't want to use pm_runtime_get() at this point. To read the revision register, let's just enable the all the clocks for the interconnect target module during init even if the optional clocks are not needed. That way we can read the revision register to configure the quirks needed for PM runtime. Signed-off-by: NTony Lindgren <tony@atomide.com>
-
- 01 4月, 2019 5 次提交
-
-
由 Tony Lindgren 提交于
At least McPDM module depends on an external optional clock to be usable. To make handling of the McPDM clock easier in the following patches, let's add separate functions for handling the main clocks and the optional clocks. Let's also add error handling to shut down already enabled clocks while at it. Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Tony Lindgren 提交于
Let's move the legacy idle and enable into separate functions to simplify PM runtime functions a bit. Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Tony Lindgren 提交于
We can make sysc_write() and sysc_child_pm_domain static as noted by sparse. Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Tony Lindgren 提交于
We have ti,no-idle in use in addition to ti,no-idle-on-init but we're missing handling for it in the ti-sysc interconnect target module driver. Let's also group the idle defines together and update the binding documentation for it. Cc: devicetree@vger.kernel.org Reviewed-by: NRob Herring <robh@kernel.org> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Tony Lindgren 提交于
If we return early before ddata->clocks have been allocated we will get a NULL pointer dereference in sysc_unprepare(). Let's fix this by returning early when no clocks are allocated. Fixes: 0eecc636 ("bus: ti-sysc: Add minimal TI sysc interconnect target driver") Signed-off-by: NTony Lindgren <tony@atomide.com>
-
- 15 3月, 2019 3 次提交
-
-
由 Aaron Ma 提交于
Add a non-NULL check to fix potential NULL pointer dereference Cleanup code to call function once. Signed-off-by: NAaron Ma <aaron.ma@canonical.com> Fixes: 2bf9a0a1 ('iommu/amd: Add iommu support for ACPI HID devices') Signed-off-by: NJoerg Roedel <jroedel@suse.de>
-
由 David Hildenbrand 提交于
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: NJulien Grall <julien.grall@arm.com> Tested-by: NJulien Grall <julien.grall@arm.com> Signed-off-by: NDavid Hildenbrand <david@redhat.com> Reviewed-by: NJuergen Gross <jgross@suse.com> Signed-off-by: NJuergen Gross <jgross@suse.com>
-
由 Dave Rodgman 提交于
lzo-rle gives higher performance and similar compression ratios to lzo. Link: http://lkml.kernel.org/r/20190205155944.16007-4-dave.rodgman@arm.comSigned-off-by: NDave Rodgman <dave.rodgman@arm.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 14 3月, 2019 24 次提交
-
-
由 Sagar Biradar 提交于
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: NSagar Biradar <Sagar.Biradar@microchip.com> Reviewed-by: NDave Carroll <david.carroll@microsemi.com> Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
-
由 Dan Carpenter 提交于
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: NDan Carpenter <dan.carpenter@oracle.com> Acked-by: NJames Smart <james.smart@broadcom.com> Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
-
由 Xin Long 提交于
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: NXiumei Mu <xmu@redhat.com> Signed-off-by: NXin Long <lucien.xin@gmail.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Bryan Whitehead 提交于
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: NBryan Whitehead <Bryan.Whitehead@microchip.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Sagi Grimberg 提交于
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: NSteve Blightman <steve.blightman@oracle.com> Suggested-by: NOliver Smith-Denny <osmithde@cisco.com> Signed-off-by: NSagi Grimberg <sagi@grimberg.me> Reviewed-by: NOliver Smith-Denny <osmithde@cisco.com> Tested-by: NOliver Smith-Denny <osmithde@cisco.com> Signed-off-by: NChristoph Hellwig <hch@lst.de> Signed-off-by: NJens Axboe <axboe@kernel.dk>
-
由 Christoph Hellwig 提交于
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: NChristoph Hellwig <hch@lst.de> Reviewed by: Chaitanya Kulkarni <chaitanya.kulkarni@wdc.com> Tested-by: NSagi Grimberg <sagi@grimberg.me> Signed-off-by: NJens Axboe <axboe@kernel.dk>
-
由 Christoph Hellwig 提交于
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: NChristoph Hellwig <hch@lst.de> Reviewed-by: NKeith Busch <keith.busch@intel.com> Reviewed-by: NMax Gurtovoy <maxg@mellanox.com> Tested-by: NSagi Grimberg <sagi@grimberg.me> Signed-off-by: NJens Axboe <axboe@kernel.dk>
-
由 Christoph Hellwig 提交于
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: NChristoph Hellwig <hch@lst.de> Reported-by: NSagi Grimberg <sagi@grimberg.me> Reviewed-by: NKeith Busch <keith.busch@intel.com> Reviewed-by: NMax Gurtovoy <maxg@mellanox.com> Tested-by: NSagi Grimberg <sagi@grimberg.me> Signed-off-by: NJens Axboe <axboe@kernel.dk>
-
由 Christoph Hellwig 提交于
Just opencode the two function calls in the caller. Signed-off-by: NChristoph Hellwig <hch@lst.de> Reviewed-by: NKeith Busch <keith.busch@intel.com> Reviewed-by: NMax Gurtovoy <maxg@mellanox.com> Reviewed-by: NChaitanya Kulkarni <chaitanya.kulkarni@wdc.com> Tested-by: NSagi Grimberg <sagi@grimberg.me> Signed-off-by: NJens Axboe <axboe@kernel.dk>
-
由 Christoph Hellwig 提交于
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: NChristoph Hellwig <hch@lst.de> Reviewed-by: NKeith Busch <keith.busch@intel.com> Tested-by: NMing Lei <ming.lei@redhat.com> Signed-off-by: NJens Axboe <axboe@kernel.dk>
-
由 James Smart 提交于
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: NNigel Kirkland <nigel.kirkland@broadcom.com> Signed-off-by: NJames Smart <jsmart2021@gmail.com> Reviewed-by: NEwan D. Milne <emilne@redhat.com> Signed-off-by: NChristoph Hellwig <hch@lst.de> Signed-off-by: NJens Axboe <axboe@kernel.dk>
-
由 James Smart 提交于
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: NNigel Kirkland <nigel.kirkland@broadcom.com> Signed-off-by: NJames Smart <jsmart2021@gmail.com> Reviewed-by: NEwan D. Milne <emilne@redhat.com> Signed-off-by: NChristoph Hellwig <hch@lst.de> Signed-off-by: NJens Axboe <axboe@kernel.dk>
-
由 James Smart 提交于
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: NJames Smart <jsmart2021@gmail.com> Reviewed-by: NSagi Grimberg <sagi@grimberg.me> Signed-off-by: NChristoph Hellwig <hch@lst.de> Signed-off-by: NJens Axboe <axboe@kernel.dk>
-
由 James Smart 提交于
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: NMike Snitzer <snitzer@redhat.com> Signed-off-by: NJames Smart <jsmart2021@gmail.com> Reviewed-by: NSagi Grimberg <sagi@grimberg.me> Reviewed-by: NHannes Reinecke <hare@suse.com> Reviewed-by: NMike Snitzer <snitzer@redhat.com> [hch: small coding style fixup] Signed-off-by: NChristoph Hellwig <hch@lst.de> Signed-off-by: NJens Axboe <axboe@kernel.dk>
-
由 James Smart 提交于
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: NChaitanya Kulkarni <chaitanya.kulkarni@wdc.com> Signed-off-by: NJames Smart <jsmart2021@gmail.com> Signed-off-by: NChristoph Hellwig <hch@lst.de> Signed-off-by: NJens Axboe <axboe@kernel.dk>
-
由 Yufen Yu 提交于
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: NYufen Yu <yuyufen@huawei.com> Reviewed-by: NSagi Grimberg <sagi@grimberg.me> Reviewed-by: NBart Van Assche <bvanassche@acm.org> Signed-off-by: NChristoph Hellwig <hch@lst.de> Signed-off-by: NJens Axboe <axboe@kernel.dk>
-
由 Yufen Yu 提交于
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: NYufen Yu <yuyufen@huawei.com> Signed-off-by: NChristoph Hellwig <hch@lst.de> Signed-off-by: NJens Axboe <axboe@kernel.dk>
-
由 Sagi Grimberg 提交于
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: NSagi Grimberg <sagi@grimberg.me> Signed-off-by: NChristoph Hellwig <hch@lst.de> Signed-off-by: NJens Axboe <axboe@kernel.dk>
-
由 Keith Busch 提交于
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: NKeith Busch <keith.busch@intel.com> Reviewed-by: NSagi Grimberg <sagi@grimberg.me> Signed-off-by: NChristoph Hellwig <hch@lst.de> Signed-off-by: NJens Axboe <axboe@kernel.dk>
-
由 Keith Busch 提交于
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: NKeith Busch <keith.busch@intel.com> Reviewed-by: NSagi Grimberg <sagi@grimberg.me> Signed-off-by: NChristoph Hellwig <hch@lst.de> Signed-off-by: NJens Axboe <axboe@kernel.dk>
-
由 Max Gurtovoy 提交于
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: NMax Gurtovoy <maxg@mellanox.com> Reviewed-by: NSagi Grimberg <sagi@grimberg.me> Reviewed-by: NJohannes Thumshirn <jthumshirn@suse.de> Signed-off-by: NChristoph Hellwig <hch@lst.de> Signed-off-by: NJens Axboe <axboe@kernel.dk>
-
由 Hans de Goede 提交于
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=1687065Signed-off-by: NHans de Goede <hdegoede@redhat.com> Acked-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: NJarkko Nikula <jarkko.nikula@linux.intel.com> Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
-
由 Hans de Goede 提交于
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: NHans de Goede <hdegoede@redhat.com> Reviewed-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: NJarkko Nikula <jarkko.nikula@linux.intel.com> Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
-
由 Wolfram Sang 提交于
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: NHsin-Yi Wang <hsinyi@chromium.org> Fixes: e94bc5d1 ("i2c: add helpers to ease DMA handling") Signed-off-by: NWolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: NHsin-Yi Wang <hsinyi@chromium.org> Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
-
- 13 3月, 2019 1 次提交
-
-
由 Stephen Rothwell 提交于
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: NStephen Rothwell <sfr@canb.auug.org.au> [bjorn: Extended commit message] Signed-off-by: NBjorn Andersson <bjorn.andersson@linaro.org>
-